Re: Debugging Help (X10i on OctoPOS)
Brian Beuning <bbeuning-gQiW9Mwg1h1Wk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <[email protected]> |
The simplest explanation is the GC is freeing an object that is still in use. There are numerous ways this can happen from misconfiguring the GC code. Does the GC know how to find thread stacks on your OS? Do you need to set INTERIOR_POINTERS? ----- Original Message ----- From: "Andreas Zwinkau" <[email protected]> To: "Ivan Maidanski" <ivmai-JGs/[email protected]> Cc: gc-V9/[email protected] Sent: Wednesday, January 15, 2014 7:58:33 AM Subject: Re: [Gc] Debugging Help (X10i on OctoPOS) Am 15.01.2014 13:03, schrieb Ivan Maidanski: > My suggestion is set data watch for vptr after it is allocated to find out which code modifies it after deallocation. The vptr is not modified. I do not see how watchpoints might help here? The vptr should probably be modified (set to 0), when the GC frees it, but gdb shows that it still points to the vtable. I think the possibility that bdwgc has a bug in sweep is quite small, since the other code (OS,compiler,runtime) is much less mature. This means somewhere a vptr is stored into already-freed memory. _______________________________________________ Gc mailing list Gc-V9/[email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/