Re: hang on leopard

Desktop wxRuby
1

Hi Alex,

Finally, I got my code to work properly by not using the show(true) and
show(false) pair within a thread in the classes that subclass from
Dialog. The symptoms I experienced if you put the show(true/false) pair
within a Thread, you get the following problems:

  1. The entire application hangs … beach ball spinning in leopard.
  2. I have seen several segmentation fault during my test the past few
    days.
  3. The application kept printing the following errors once every few
    tests.

2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not
properly removed. Some code has jumped or returned out of an
NS_DURING…NS_HANDLER region without using the NS_VOIDRETURN or
NS_VALUERETURN macros.

and

Mon Feb 18 16:00:06 ruby[686] :
CGContextRestoreGState: invalid context

Now, here are the high level code that causes the problem on 10.5.2 with
ruby version 1.86 and wxruby 1.9.4 (The same source code does not cause
any problem on Windows XP running under Parallels on OS X):

============================================
PROBLEMATIC CODE THAT CAUSES HANG ON LEOPARD
Within 15 times the button is hit (as soon
as 1 or 2 hits sometimes)

def on_button(event)
$dialog1.start
end

class dlg1:
def start
if (@dialog1Thread == nil)
@dialog1Thread = Thread.new {
loop do
$dialog1.show(true)
$dialog2.start
…
$dialog1.show(false)
Thread.stop
end # loop do
} # @flashModeThread = Thread.new
else # if (@ dialog1Thread == nil)
@dialog1Thread.run
end # if (@ dialog1Thread == nil)
end # def start

class dlg2:
def start
if (@dialog2Thread == nil)
@dialog2Thread = Thread.new {
loop do
$dialog2.show(true)
…
$dialog2.show(false)
Thread.stop

         end # loop do
    }
else
    @ dialog2Thread.run
end

end # dialog2Thread

=================================================
MOVING show(true/false) pair out from the dialog
thread to the on_button solves the issue

def on_button(event)
$dialog1.show(true)
$dialog2.show(true)
$dialog1.start
if $WaitTimer == nil
$WaitTimer = Wx::Timer.every(1) do
if $dialog2.done == true
$dialog1.show(false) if $dialog1 != nil
$dialog2.show(false) if $dialog2 != nil
$WaitTimer.stop
end
end
else
$WaitTimer.start
end

end

From my testing, it surely looks like there is a problem with using Wx’s show(true/false) within ruby’s Thread.

But hopefully you can see something else that I might had done wrong,
because it is much easier for me to fix my code :slight_smile: :slight_smile: :slight_smile:

  ____________________________________________________________________________________

Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

2

Zhang P. wrote:

Finally, I got my code to work properly by not using the show(true)
and show(false) pair within a thread in the classes that subclass from
Dialog. The symptoms I experienced if you put the show(true/false)
pair within a Thread, you get the following problems:
…
From my testing, it surely looks like there is a problem with using
Wx’s show(true/false) within ruby’s Thread.
Thanks for posting your code. I agree with your analysis … but …

The wxWidgets documentation and mailing list are clear that GUI calls in
wxWidgets (C++), like show(), should be restricted to a single thread
only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets,
but some of the issues may be the same. In particular, the error message
that you are getting sounds like OS X is complaining that execution is
being prematurely switched out of some core operation. That sounds to me
like a possible thread problem.

But hopefully you can see something else that I might had done wrong,
because it is much easier for me to fix my code
I think it is a primarily a design problem. You have a lot of globals,
and a lot of Threads. In general, if you have a background task running
in a ruby thread, notifications about the status of that thread’s work
should be handled either by a properly shared variable (using Mutex if
needed), or by posting a Wx::Event from the slave thread to the master
GUI thread.

If you were able to say a bit more about why you are using these
Threads, we’d be happy to be more specific about a safer alternative.

alex