On 22/01/2011, at 2:30 AM, Dave Goodell wrote: > On Jan 20, 2011, at 6:43 PM CST, john skaller wrote: > >> >> OK, so I do this now: > ... >> if(debug) >> fprintf(stderr, "Check if *%p=%p is a pointer\n",i,*(void**)i); >> scan_object(*(void**)i, reclimit); > ... >> The VALGRIND macro there doesn't seem to be working, I must be >> doing something wrong. I'm trying to just mark the whole stack as defined. >> >> Here's output: > ... > > The way that I read this output is that your range variable and the data in > that range is probably defined because Valgrind isn't flagging i or the value > at address i when you perform the "Check if" fprintf above.
Good point.. > Rather, it's flagging an fprintf inside of scan_object on line 451, whose > output you did not include. Maybe it's the reclimit variable? I shouldn't think so, though it's hard to be sure of anything. Scan object look to see if the "pointer" value it gets is actually a pointer into the heap. If so, it looks at the pointer inside the pointed at object (recursively). I know where the pointers are because I know the type of every heap object. It doesn't chase down the "pointer" unless its an actual pointer into the heap: it doesn't chase ints, raw C pointers (not Felix heap allocated), or pointers into the stack or static storage. In this program there is only ONE data structure on the heap: list nodes. Which contain exactly one pointer (to the next node). There are no list nodes on the stack. The "pointers" used for lists are actually tagged pointers: struct _uctor_ { int variant; void *data; }; variant = 0 means "end of list" and 1 means a node with data in it is being pointed at. [So a node the last node has a value in it and a pointer with variant 0 and "data=NULL"]. It is the "variant" which is sometimes overwritten with a value like 99762976, it should be only 0 or 1, my has switches on the variant, which include a wildcard for values other than 0 or 1, which cause a diagnostic to be printed "match failure" and then abort the program. > >> ==7159== Uninitialised value was created by a stack allocation >> ==7159== at 0x10000E492: >> flx::gc::collector::flx_collector_t::mark(std::vector<flx::pthread::memory_range_t, >> std::allocator<flx::pthread::memory_range_t> >*) (flx_collector.cpp:337) > > It's odd that the stack allocation is attributed to line 337, which AFAICT is > the line where scan_object is called. Is there some sort of odd automatic > C++ temporary allocation happening here that I can't see because some other > code isn't shown here or (more likely) my C++ is too rusty somehow? I don't think so. > Perhaps under optimization an uninitialized and otherwise-unused reclimit > variable only gets created at the time that the arguments to scan_object are > pushed onto the stack? Well that's possible, but I'm doing a debug build, I *think* that doesn't do C++ optimisation (normally I run with -O3 on gcc). The nasty thing is now it is working, some quirk has changed something.. :) -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users