[Gc] Patch to prevent deep recursion from a finalizer
ivmai at mail.ru
Sat Jun 20 04:33:37 PDT 2009
The attached patch tries to prevents deep recursion inside GC_notify_or_invoke_finalizers() if a client finalizer allocates memory.
Note: the code is a bit tricky (to not prohibit finalization when handling out-of-memory or when a client finalizer completes abruptly (due to longjmp or exception thrown)).
The patch also contains the code (not related to the subject) avoiding data races for GC_finalizer_notifier var (I'll send the patch dealing with data races in other files some time later).
* finalize.c (GC_fail_count): New external variable declaration.
* finalize.c (GC_finalizer_nested, GC_finalizer_skipped): New
thread-local global variables (used internally by
* finalize.c (GC_finalize): Reset GC_finalizer_nested value if last
heap expansion failed.
* finalize.c (GC_finalize_all): Add comment for notifier proc.
* finalize.c (GC_finalize_all): Access GC_finalizer_notifier and
GC_finalize_on_demand variables holding the lock (to avoid data
* finalize.c (GC_notify_or_invoke_finalizers): Ditto (for GC_gc_no,
* finalize.c (GC_finalizer_notifier): Add comment.
* finalize.c (GC_notify_or_invoke_finalizers): Skip some
GC_invoke_finalizers() calls to minimize the probability of deep
recursion when a client finalizer tries to allocate GC memory.
"Talbot, George" <Gtalbot at locuspharma.com> wrote:
> 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.
It would be good if You try this patch with your 'unfixed' program.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3812 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20090620/22836913/koi8-rQdiff1025Fcvs.obj
More information about the Gc