[Fxruby-users] Re: GC Bug in 1.8.0 and FXRuby
Status: Inactive
Brought to you by:
lyle
|
From: <ly...@kn...> - 2003-08-08 19:08:37
|
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
|