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
[email protected]
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
