|
From: john s. <sk...@us...> - 2011-01-19 04:57:05
|
On 19/01/2011, at 5:58 AM, Dave Goodell wrote: > A few things that might help you here: > > 1) Build your program with debugging information, which will help you to understand exactly which line is causing a problem in your stack traces. Done. > 2) Tracking down "uninitialized value" warnings is much easier if you use the "--track-origins=yes" option to Valgrind. Also done. Told me the function "making" the original uninit value, but I already knew that anyhow. I needed to know which variable. It's likely valgrind is being too smart: the code is looking on the "current" stack for pointers, it's likely some words were part of a struct with an uninit value, this would be harmless. The values are looked up in a "table" (actually a JudyArray) to see if they're managed pointers. So it's ok if they're uninitialised values. My problem is that something is overwriting valid storage, either a bug in my list handling code or the GC deleting reachable objects. I can't tell which. Both pieces of code "seem to work" at least some of the time. There's never a problem *unless* the GC is called, but that doesn't prove its the GC, its possible the GC is deleting an object and a new one is created at the same address (malloc will certainly do this), and then the overwrite is causing a problem. Still .. the code *works* when it doesn't crash. > 3) I have a pretty limited understanding of Valgrind's handling of stack red zones, but there's a handy comment in memcheck/mc_main.c that sheds some light on the situation: > > ----8<---- > Dealing with stack redzones, and the NIA cache > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This is one of the few non-obvious parts of the implementation. > > Some ABIs (amd64-ELF, ppc64-ELF, ppc32/64-XCOFF) define a small > reserved area below the stack pointer, that can be used as scratch > space by compiler generated code for functions. In the Memcheck > sources this is referred to as the "stack redzone". The important > thing here is that such redzones are considered volatile across > function calls and returns. So Memcheck takes care to mark them as > undefined for each call and return, on the afflicted platforms. > Past experience shows this is essential in order to get reliable > messages about uninitialised values that come from the stack. > ----8<---- > > The key bit is that Valgrind is marking the whole red zone as "undefined" at function entrance/exit, so only areas that are actually written during that function are potentially going to be marked as "defined". Yeah, I see, so actually the "red zone" is only safe to use within a function as "scratch" area. -- john skaller sk...@us... |