I went back and fixed my program so as to not allocate memory in a destructor (finalizer) that's marked for cleanup. I still think this ought to get fixed, if possible.
Thanks for looking at my trace.
--
George T. Talbot
<gtalbot at locuspharma.com>
________________________________________
From: gc-bounces at napali.hpl.hp.com [gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski [ivmai at mail.ru]
Sent: Thursday, June 18, 2009 5:45 PM
To: gc at napali.hpl.hp.com
Subject: Re: [Gc] Exciting recursive invocation of GC_invoke_finalizers()...
Hi!
"Talbot, George" <Gtalbot at locuspharma.com> wrote:
> Hi all,
>> 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.
Yes, this is known problem (to me).
>> 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.
But the solution is not so easy (because of out-of-mem handling).
I thought even about "lazy" finalization (which could also minimize the execution time of a single GC_malloc() call if we have notifier installed) but gave up (due to the above problem).
I think I'll a have another closer look at it...
>> 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.
Yes, Java ingores all exceptions thrown by finalize().
Java implements it as:
static void GC_CALLBACK java_finalizer( void *obj, void *client_data ) {
try { // or setjmp()
obj->finalize();
} catch (...) {
}
}
Bye.
_______________________________________________
Gc mailing list
Gc at linux.hpl.hp.comhttp://www.hpl.hp.com/hosted/linux/mail-archives/gc/