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

Talbot, George Gtalbot at locuspharma.com
Thu Jun 4 12:40:18 PDT 2009

Hi all,

I asked a while back about finalization cycle warning messages, and I've solved my problem.

I was declaring a class something like this:

class X: public gc_cleanup
        typedef std::map<int, int, gc_allocator<std::pair<int, int> > > map_t;

        map_t           m_map;

The finalization cycle warning would occur because there's a pointer back to m_map from the data allocated by m_map.  On Linux w/GCC 4.1.3, std::map<> is a red-black tree, and there's a pointer in each tree node to its parent.  The top tree node is pointing back to class X.

gc_cleanup appears to be doing the right thing registering finalizers using the _ignore_self variant.  However that doesn't eliminate the pointer cycle, and the loop in GC_finalize is still picking up the pointer cycle because X has a finalizer, even though m_map's nodes technically do not.

My fix was to change m_map to be a pointer and allocate the map in the constructor for class X.

Question: If the warning is printed, even though there doesn't appear to be a _finalization_ cycle (though there is a pointer cycle), will the finalizer for X run?

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.

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?  Will they be applied, do you think?  Are they in the right format?

George T. Talbot
<gtalbot at locuspharma.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomicize_print_callers_reentry.patch
Type: application/octet-stream
Size: 3077 bytes
Desc: atomicize_print_callers_reentry.patch
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20090604/87ee5c52/atomicize_print_callers_reentry.obj

More information about the Gc mailing list