Charlie,

I went back and read this thread completely.
Then, I had a look at the gc.c in my patched ruby 1.6.8
(fear not, the GC hasn't changed much over the years :-)

There certainly is no attempt to respect data dependencies 
during the final cleanup before exit.  rb_gc_call_finalizer_at_exit()
ends with a loop that simply frees (and finalizes) every object on
all heaps.   I believe this explains Nobu's comment that free functions
may not reference other objects.

After looking this over, I tend to agree with Nobu's later comment that
reference counting may be useful here.  XML::Node::Set object might:

 1. increment a reference count in the parent XML document object, and 
 2. have each document object include a flag that indicated that Ruby's GC
had
     attempted to free it while its reference count was non-zero.

In this case:
 3. The XML::Node::Set's dfree would decriment the document's refcount, and
 4. only if it reached zero and the document object's dfree had already been
called,
     would it would also free the document object.

The general approach of making the final cleanup respect data dependencies
is not practical (or possible) because objects may have circular dependency
graphs.

- brent


Nobu wrote:

> Which object is the problem?  Reference count may be useful.

Charlie Replied:

The specifics of this issue are:

1.  Open a XML::Document
2.  Call Document#find which returns an XML::Node::Set
3.  Within libxml, XML::Node::Set maintains a set of pointers to nodes 
that are owned by the document.
4.  Ruby process starts exiting
5.  XML::Document is freed
6.  XML::Node::Set is freed - but when it iterates over its list of 
nodes to pointers a segmentation fault occurs.

...
 


-- 
View this message in context: http://www.nabble.com/-ruby-core%3A17694--Mark-functions-not-called-on-exit-tp18356849p18475985.html
Sent from the ruby-core mailing list archive at Nabble.com.