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 skal...@users.sourceforge.net ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
