On 21/01/2011, at 2:55 AM, Dave Goodell wrote:
>
> Valgrind tracks the V bits (validity bits) for registers too, so the validity
> of any pushed register values on the stack will depend on the validity of the
> register contents before the push.
OK thx .. I haven't looked at the VEX machine.
> If you follow that, then I think the best approach is to adapt the client
> request code sketch that I posted before for scanning the whole stack:
BTW: it says in the docs that #including valgrind has a "tiny overhead" which
won't be
noticed "except in inner loops perhaps". I have not yet looked at this in
detail.
Is there really a cost (if you don't use it).
> ----8<----
> #define RZ_SZB (128)
> char *sp = /* stack pointer value */;
> char vbits[RZ_SZB] = {0};
> VALGRIND_GET_VBITS(sp-RZ_SZB, vbits, RZ_SZB);
> VALGRIND_MAKE_MEM_DEFINED(sp-RZ_SZB, RZ_SZB);
> /* ... scan the red zone here ... */
> VALGRIND_SET_VBITS(sp-RZ_SZB, vbits, RZ_SZB);
> ----8<----
I can try that, but really the problem isn't reading uninitialised values.
My theory is gc is deleting reachable store: the actual bug is NOT
reading some thing it should not be :)
>>
>> Unfortunately running Valgrind is one of the things the bug is sensitive to,
>> it runs and hides when running Valgrind :)
>
> That happens sometimes, especially if there are threads in your program
> because Valgrind changes the way that threads are scheduled.
No threads, at least none I know of.
The actual program is just "ls regexp" where regexp is a Google Re2 (perl)
regexp.
The code actually collects all the files in a list before printing them,
basically to test
the subroutine that collects all the files in a list, since that's going into
my library.
> Valgrind also replaces the standard malloc and some other routines, which can
> change the way that they behave. Hopefully if you can clean up the false
> positives from your stack-scanning code then you will be able to find some
> bugs from the remaining warnings.
That would be nice but it is unclear. Consider: the only way** a GC could cause
the problem of an over-write would be to delete a reachable object.
** unless there were some stupid bug in the GC, I did have one: chasing
pointers down with recursion .. blows the stack on a long enough list.
--
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
