Re: [Fxruby-users] bug: descending FXTreeItem causes coredump? [LONG]

[Kevin B. <kev...@sy...>]

The short synopsis of the solution is, "make sure that the link between 
> the deceased Ruby object and the still-living C++ object gets broken at 
> the right time", and I'm still trying to decide when that right time is. 
> But I should be able to get a fix in the next day or so, at the latest.

As I mentioned, I have written my own Ruby extension.  I had (and am
still having in one place) the same problem as FXRuby.  The API I
wrapped (manually, not with SWIG) does not keep track of object
references (no parent->child connection, only child->parent), and
expects the programmer to destroy objects in an orderly fashion.  Of
course, Ruby choked on this, since, as you said, at finalization, it
destroys the objects (almost) randomly.  My solution was to make all the
objects remember each other, and whenever a child is destroy, it has the
parent remove it from it's "children", and if the parent is destroyed it
tells all the children to destroy themselves first.

The difference from FXRuby is that I DESTROY the items, even though the
Ruby object may still exist.  The Ruby VALUEs outlive the C objects they
point to, whereas in FXRuby, the C++ objects outlive their Ruby VALUEs.

My reasoning was: as long as I have the marking right, I'll never have
Ruby VALUEs pointing to uninitialized C objects.  At finalization, the
Ruby VALUEs will never be used again, so it doesn't matter at that
point.

Not fully comprehending the FXRuby internals (though I have looked at it
quite a bit):

What I think should happen is that any owned object must use it's
"owner" to remove itself and/or unregister itself.  I.e. in
"delete_if_not_owned", there should be a call to "owner->remove(self)"
just before FXRbUnregisterRubyObj.

Said differently, if Ruby destroys an owned object, the owner should
first UNOWN the object.  So, in the case of the above:

If 4 items are added as children of one another, and the first is freed
by Ruby, it's freefunc should call the TreeList->removeItem(self) BEFORE
it unregisters itself.  This will remove all the children items (and
their unregistering their Ruby objects), etc., etc.

I'd help if I had time.  Gotta finish my FXRuby app! :)

Kevin