[Gc] Figured out my problem with finalization cycles. Useful patchattached.

Talbot, George Gtalbot at locuspharma.com
Fri Jun 5 06:19:29 PDT 2009


Hi,

Ivan, thanks for looking at the patch.

Ok.  This version of the patch fixes the issue identified by Ivan where AO_fetch_and_add1() isn't available by reverting to the previous behavior on such a platform.

What would I need to do to GC_print_backtrace() to have it detect pointer cycles while it's printing; note that at the point when GC_finalize() is calling it, GC_finalize() appears to be marking to find cycles involving finalizeable items.

This patch is current w.r.t. CVS as of ~9:15AM EST 6/5/2009.

Thanks.

--
George T. Talbot
<gtalbot at locuspharma.com>


> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Friday, June 05, 2009 3:36 AM
> To: gc at linux.hpl.hp.com
> Cc: Talbot, George
> Subject: Re: [Gc] Figured out my problem with finalization cycles. Useful
> patchattached.
>
> Hi!
>
> "Talbot, George" <Gtalbot at locuspharma.com> wrote:
> > Hi all,
> > ...
> > To help debug this I made a small fix to GC_print_callers in os_dep.c.
> GC_print_callers was taking the LOCK() so as to increment and decrement
> the reentry_count.  I changed reentry_count to AO_t and used the
> libatomicops operations to get rid of the lock.  I then added a #ifdef'd
> GC_print_backtrace() right after the warning in GC_finalize().  I also
> removed the UNLOCK() and LOCK() around GC_generate_random_backtrace() in
> GC_notify_or_invoke_finalizers() as it was no longer needed.
> >
> > Attached is the patch, though it isn't yet perfect.
>
> AO_fetch_and_add/sub1() are not always available, so guard them (falling
> back to locking) with AO_HAVE_fetch_and_add1.
>
> >
> > Question:  How do I get GC_print_backtrace() to stop when it's printing
> a cycle?
> >
> > I currently have to ctrl-C the program when it catches a finalization
> cycle when I have debug turned on.
> >
> > One more question:  Is my sending of these patches useful to anyone?
> Sure.
>
> > Will they be applied, do you think?  Are they in the right format?
>
> The format is right.
>
> >
> > --
> > George T. Talbot
> > <gtalbot at locuspharma.com>
>
> Bye.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomicize_print_callers_reentry.patch
Type: application/octet-stream
Size: 4345 bytes
Desc: atomicize_print_callers_reentry.patch
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20090605/44d57ef7/atomicize_print_callers_reentry.obj


More information about the Gc mailing list