From: Matt Armstrong <matt@...>
Date: 2002-03-08T15:01:16+09:00
Subject: Re: Talking Trash About Ruby

Lyle Johnson <lyle@users.sourceforge.net> writes:

> I'm trying to debug a GC-related problem for FXRuby. The symptom is
> that one of the Ruby Data objects created by FXRuby is getting its
> "mark" function called after it should no longer be reachable. That
> is to say, unless I misunderstand Ruby's scoping rules, no other
> object should be able to reach "see" this object and so its mark
> function shouldn't be called.

Do you play around with finalizers in the code at all?  If not
careful, you can create a loop that the GC system won't catch.  See
[ruby-talk:33837] aka http://www.ruby-talk.org/33837 and the comment
on this code:

    loop {
        string = "a"
        ObjectSpace.define_finalizer(string) {
        }
    }

(In short, the block passed to define_finalizer contains "string" in
its scope, so the instance is never collected since its own finalizer
references it.)

I'm not aware of other pitfalls that can cause instances to
mysteriously live forever.


> This is a big problem because the C++ object that this Data object
> refers to has in fact been destroyed by this point, and so the Ruby
> Data object has a "dangling" pointer.

I agree with the previous comment -- either you should make sure the
C++ instance lives as long as the Ruby one, or the C++ instance must
zero out the Ruby instance's pointer to it when it is destroyed.  If
you don't do this, it will always be possible for people to save a
reference to the Ruby instance (say, in a global variable), cause the
Fox C++ object to be destroyed, and then crash Ruby by accessing the
Ruby instance.

But I don't know much about the GC itself, so I can't comment on your
more specific questions about how to debug "mystery" references.

-- 
matt