Hi all, I''m seeing reproducable crashes in my wxruby application under circumstances: The application runs a WxGrid backed with my own subclass of TableBase. The application works fine. Trying to open a FileDialog I get a crash on Windows ONLY. There is no crash report, no segfault message, the application simply quits at the call to FileDialog#show_modal Here is something that I hope raises someone''s suspicion: The crash happens ALWAYS after I scrolled through the WxGrid using a mouse wheel. I do not handle mousewheel events in the grid. The crash NEVER happens if I do not scroll through the grid before calling to open the FileDialog, everything works just fine. Looking at the windows event viewer, I find the following log: Faulting application name: ruby.exe, version: 1.8.7.0, time stamp: 0x4c698044 Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp: 0x4ce7ba58 Exception code: 0xc0000374 Fault offset: 0x000ce653 Faulting process id: 0xb10 Faulting application start time: 0x01cc52945f2fb020 Faulting application path: C:\Ruby187\bin\ruby.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll I''m using wxruby 2.0.1 x86-mingw32 and wxwidgets 2.8.11 running on Windows 7 Ultimate x64 -- Posted via http://www.ruby-forum.com/.
the really funky part is that I can replace the GridTableBase by a
minimum/non functional implementation (see below) and the crash will
still happen. However, when I use the built-in table (Grid#create_grid)
the FileDialog will always open just fine.
I also verified the crash with wxWidgets 2.8.12
___
class ValueGrid < Wx::GridTableBase
def initialize foo, data
super()
@rows = data.size
end
def get_number_cols
2
end
def get_number_rows
@rows
end
def get_value row, col
"foobar"
end
def is_empty_cell row, col
false
end
def get_attr row, col, kind
Wx::GridCellAttr.new Wx::BLACK, Wx::WHITE, Wx::NULL_FONT,
Wx::ALIGN_LEFT, Wx::ALIGN_TOP
end
end
--
Posted via http://www.ruby-forum.com/.
Update: the crash seems to be connected to background threads. One background thread is listening on a serial interface (using hparra''s serialport). A timer triggers a call to Thread.pass() every couple of milliseconds. When I kill the serial reception in the background, the crash seems to disappear. So the question becomes: how can I open a file dialog with a background thread running, that accesses the serial interface? Thanks, T -- Posted via http://www.ruby-forum.com/.
Hello Tony, This sounds very much like a Re-entry kind of lockup, that occurs when trying to use more then one thread, in the Ruby Interpreter. And from the crashes, it very much looks like your running 1.8 line of the Ruby Interpreter. With that being the case, the 1.8 line, uses Software based Threads, or Faux threads. Meaning, that there is no secondary thread actually created on the Operating System, but instead is handled internally by the interpreter itself. We also call them Green Threads. Which is always an issue when it comes to Re-entry based code being executed. What is basically happening, is that when you run with Green Threads, the interpreter creates a stack for each green thread, that all runs on the Same Operating System thread. When the background thread is called, and some GUI Function is currently being ran (Such as a GUI Dialog, or population of a wxGrid), the program will crash, trying to handle this, cause a re-entry clause occurred when trying to execute the function, or rather, the method in question. The main thing that causes these re-entry errors, is trying to access a variable used between two different threads. Which is never a good thing. The only suggestion that I can make, is that when the GUI needs priority over the background worker threads, suspend the worker threads for the duration of the GUI execution. In other words, when showing a File Dialog, suspend the worker threads, show the dialog, once you get a response, and you can process the info in Ruby again, resume the Worker threads, then continue with processing the data. The other option, which isn''t much of an option, is to use the Ruby 1.9 line of interpreter, as it uses Native OS Threads for Ruby Threads. But you will still need to be careful of worker threads, and GUI threads, just not as insanely. hth, Mario On Fri, Aug 12, 2011 at 2:57 AM, Tony Meier <lists at ruby-forum.com> wrote:> Update: > > the crash seems to be connected to background threads. One background > thread is listening on a serial interface (using hparra''s serialport). A > timer triggers a call to Thread.pass() every couple of milliseconds. > When I kill the serial reception in the background, the crash seems to > disappear. > > So the question becomes: how can I open a file dialog with a background > thread running, that accesses the serial interface? > > Thanks, > T > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >-- Mario Steele Commander 1st XO - Geo 99 XO - STO IFT Fleet http://www.trekfederation.com http://geo99.ruby-im.net -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20110812/87b007b9/attachment.html>
Hey Mario, appreciate your answer. I''m well aware of green vs. native threads. Of course I tried blocking the worker threads, just that isn''t always easy when you''re communicating with outboard equipment as I do. Plus: A file dialog shouldn''t really cause any access to shared variables either. I tried switching to 1.9 (after I spent a while getting it to run) but the result was pretty much the same. It''s sad, having spent over a year into this. But I''m giving up. Some (hopefully constructive) feedback on my collected experiences will follow in another thread. Thanks again for taking your time to answer me. T -- Posted via http://www.ruby-forum.com/.