[Gc] Could memory corruption cause a zombie using GC 6.2

Alec Orr Alec.Orr at wbemsolutions.com
Fri Feb 20 11:57:05 PST 2004


RH8 Linux
GC6.2 --enable-full-debug --enable-threads=posix --enable-static=no 
--enable-gc-assertions

Folks:

I am still looking into this one myself, but would see if anyone else 
has seen similar behavior.

On occasion I get a zombie process running a module hooked into the 
debug build of GC 6.2 (without --enable-full-debug works fine).  The 
process cannot be recovered (using gdb or otherwise).  Below is a trace 
from gdb.  In my experience, this is due to heap corruption. (we can 
switch heap models to DMALLOC - no errors reported).  Anyone else run 
into this, or can suggest a way to find this bugger (unfortunately this 
is intermittant and the object address is almost never the same).  We do 
use pthreads with no hooks into pthread_* functions.

Thanks for any suggestions,
Alec Orr

------

Initiating full world-stop collection 73 after 35948 allocd bytes
--> Marking for collection 73 after 35948 allocd bytes + 2044 wasted bytes
Collection 72 finished ---> heapsize = 237568 bytes
World-stopped marking took 10 msecs
Complete collection took 10 msecs
Leaked composite object at start: 0x8092400, appr. length: 1024
Leaked composite object at start: 0x808bf98, appr. length: 8
Leaked composite object at start: 0x808bfa8, appr. length: 8
Leaked composite object at start: 0x8069fc0, appr. length: 64
Leaked composite object at 0x8065c08 (unknown:0, sz=40)
         Call chain at allocation:
Cannot find user-level thread for LWP 22920: generic error




More information about the Gc mailing list