[Fxruby-users] Re: GC Bug in 1.8.0 and FXRuby

[<ly...@kn...>]

On Thu, 7 Aug 2003 23:52:48 -0300, "Allen Mitchell" <aj...@nb...>
wrote :

> Lyle, I'm stilling trying to narrow down the issue I was having.  I
> downloaded your latest copy of FXRuby 1.0.25 and have rebuilt with that, but
> the problem still exists.

OK.

> It is consistent, when I manipulate the list on the left, I use a thread to
> populate the table on the right and just by moving the selection on the
> left, I can cause the access violation.  It always points to the same
> location  ....  21 bytes into the rb_newobj.  I'm guessing, but maybe I'm
> doing something wrong in the FXRuby code that causes objects to be marked
> incorrectly and this causes the corruption in the GC.

You should not be able to do anything wrong in your Ruby code to cause this
to happen ;) That is to say, the fact that this crash is happening to you
indicates a bug in my code; worst case, if you've done something "wrong",
FXRuby should be smart enough to raise an exception or something more
graceful than just dumping core. There is of course a remote chance that
there's a bug in Ruby's GC code, but I think someone else would have caught
that.

> I'm going to simplify the application and attempt to get it down to
> something I can easly send to you, but I'm not there yet.

OK. Yes, this seems like the best path.

> Disabling GC solves the problem, but isn't practical.

Yes, I completely agree.

> Maybe you can answer another question for me.  I'm used to a windows
> environment where events handlers receive only one event and no further
> events are handled until the first event handler finishes.  I have
> demonstrated that in my application, when I get the sel_selected event and
> start to handle it, I can receive a second one while I am still in the
> handler.  Is this normal behavior?  If so, is there a way to force the
> messages to be handled only one at a time?  If not, any suggestions where to
> look for it?

True Windows events (i.e. those generated by the operating system) should be
dispatched synchronously, one at a time, as you described. There may be some
of those that are asynchronous, but it's not too many. But what you are
/probably/ seeing is that some FOX messages get sent as a side effect of
certain method calls.

For example, if you consider the FXList class:

    http://www.fxruby.org/doc/api/classes/Fox/FXList.html

you'll see that when a list item is selected, the FXList can send a
SEL_SELECTED message to its target, and so you might write a handler for that:

    aList.connect(SEL_SELECTED) { |theList, sel, ptr|
        ... do something ...
    }

Now suppose that your handler code wants to select some /other/ item as a
result of this first item being selected. Your handler might look like this:

    aList.connect(SEL_SELECTED) { |theList, sel, ptr|
        # Also select the sixth item in the list...
        theList.selectItem(5, true)
    }

Now if you check the documentation for FXList#selectItem, you'll see that
when the second argument (notify) is true, that this causes a SEL_SELECTED
message to be fired. This happens *immediately*. As you scan the
documentation, you'll see similar notes for other methods.

So this is a possible explanation for what you're seeing. If that doesn't
seem to explain it, and if you can point out a specific example of what
you're talking about, maybe I can come up with a different explanation ;)

Hope this helps,

Lyle