In message <[EMAIL PROTECTED]>
Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Tom Hughes wrote:
>
> >>> Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed.
> >>> Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC)
> >>
> >> It's a problem with the secondary V bits table in Memcheck. That table
> >> holds the full V bits for all memory bytes that are partially defined.
> >> It's happened a couple of times, but always in situations that are
> >> impossible for me to reproduce. If you are able to reduce it to a small
> >> test, or are able to do any debugging yourself, that would be very helpful.
> >
> > It is 100% repeatable for me but, interestingly, only on my machine at
> > home. My machine at work doesn't have the same problem. Both are
> > x86_64 machines with two cores and 4Gb of memory and both are running
> > Fedora 8!
> > [...]
> > Any suggestions for the best way to debug it?
>
> The relevant code starts with this line, around line 838:
>
> /* --------------- Secondary V bit table ------------ */
>
> It's a fairly basic data structure, the only notable thing is that we
> periodically garbage collect (GC) it, ie. remove stale nodes. The easy
> first thing to try is to turn off the GC, ie. make gcSecVBitTable() do
> nothing. If that makes the problem go away, then we know that the GC is
> removing nodes it shouldn't.
Well I made that function do nothing, and it still happens...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
