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

[Lyle J. <jl...@cf...>]

Kevin Burge wrote:

> It ONLY fails if the item selected is a DIRECT subitem of an item added
> with addItemList(nil, FXTreeItem.new(...)).

Yes, it turns out that this is just a symptom of a more general problem. 
I think I have identified the basic problem and so now I need to decide 
what is the best solution (decision-making currently in progress ;)

The problem is that when the Ruby interpreter shuts down, it finalizes 
all of the still-alive objects in a more or less random order. In our 
case, it is first finalizing the two tree items, and later the tree list 
itself.

At the time the tree items are finalized in the Ruby interpreter, Ruby 
doesn't "own" the underlying C++ FXTreeItem objects and thus doesn't 
have permission to call the C++ objects' destructors. This situation is 
correctly accounted for in the FXRuby GC code; the Ruby instances go 
away, but the C++ objects hang around. It's not a memory leak since the 
FXTreeList owns those two tree item objects and will dispose of them 
later, when it is destroyed. So far, so good.

Time passes, and now it's time to finalize the tree list in the Ruby 
interpreter. As you have perhaps seen in the FOX source code, the main 
business of FXTreeList's destructor is to recursively destroy all of its 
tree items in a sort of depth-first manner. So it burrows down and 
deletes the lowest-level tree item. And since that item was the current 
item and had the focus, FOX wants to transfer the focus to the new 
current item, namely, the root-level item. It does so by calling the 
root item's virtual setFocus() member function, and that's where the 
trouble starts.

Since setFocus() is a virtual C++ member function, and since it is 
possible that you (the application writer) have overridden that virtual 
function in your Ruby code, we look up the Ruby instance associated with 
this C++ FXTreeItem object. You may recall that this Ruby object was 
finalized earlier and no longer exists, but we still find it in our map 
of C++ objects to Ruby objects, so FXRuby goes ahead and tries to invoke 
a method call (for the potentially-overridden setFocus) on it. This is 
where the seg fault occurs.

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.