Am Freitag, 7. Dezember 2007 schrieb Tom Hughes: > > Done that, and it looks like it is being created - first we get this: > > --31740-- setting line 0x75D0EA0 > > and then a bit later this: > > Memcheck: mc_main.c:959 (get_sec_vbits8): Assertion 'n' failed. > Memcheck: get_sec_vbits8: no node for address 0x75D0EA0 (0x75D0EAC) > > ==31740== at 0x3801444D: report_and_quit (m_libcassert.c:140) > > > Hmm, on rereading previous messages, all of (2) is irrelevant if > > you disabled gcSecVBitTable and the problem still exists. So > > it's either 1. or 3. Can you at least try 1. ? > > The GC is disabled, so it shouldn't be that.. > > It's getting odder and odder really.
You could run valgrind in the debugger. And set a watchpoint to the node that holds the address 0x75D0EA0 and its parent in the AVL tree. At some point the link from the root node to the node seems to get lost. This only works if the address is constant between two runs of valgrind. If this is the case you could also search for the address in the AVL tree after all modification steps and use binary search over time to find the location where it gets lost. Christoph ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-developers
