[Gc] Exciting recursive invocation of GC_invoke_finalizers()...
Gtalbot at locuspharma.com
Thu Jun 18 12:15:26 PDT 2009
Attached is a nice zip file of a 264K text file showing a backtrace from my program. I've managed to find that one can cause an exciting crash if one allocates memory from a finalization function invoked by the collector.
I'm looking right now at putting an atomic flag in GC_invoke_finalizers() or GC_notify_or_invoke_finalizers() (or both) so that only one invocation of this can be live at any one time.
I don't know that I can guarantee in my particular program that a finalizer won't allocate memory. Maybe for example it must send a text message reading "Thanks for playing, "+name+"!" just before closing a network connection, and maybe both building the string and sending the message may allocate memory. (In my case, maybe I have to tell some other process I've closed a file, for example.)
For that matter, I don't know that you can expect a guarantee that any finalizer in C++ or Java wouldn't allocate memory, so I'm guessing that this is a case that should be handled.
George T. Talbot
<gtalbot at locuspharma.com>
P.S. On a side note, I haven't done a super-careful reading of the code, but you may wish in both C++ and GCJ to have some wrapper that GC_invoke_finalizers() calls to isolate GC_invoke_finalizers() from having a C++ or Java exception thrown in a finalizer. I'm guessing that it would be a bad thing(tm) if the GC stack got unwound on in the middle of an allocation...I asked a buddy who's more of a Java expert than I and he says that he thinks that Java will continue on collecting if a finalized object throws an exception. I think right now the BDW GC might crash.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 17536 bytes
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20090618/f517b595/recursive_finalizer_crash.txt.bin
More information about the Gc