Forum: wxRuby Reproducable FileDialog crashes on Win

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
53ba108ecb05f9e1d67084cc51d2661e?d=identicon&s=25 Chloro F. (tony44)
on 2011-08-04 13:16
Hi all,

I'm seeing reproducable crashes in my wxruby application under

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:, time stamp:
Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp:
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.

Thanks for any help,
53ba108ecb05f9e1d67084cc51d2661e?d=identicon&s=25 Chloro F. (tony44)
on 2011-08-04 14:17
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. On the other hand, the
code runs fine on OSX 10.6.


class ValueGrid < Wx::GridTableBase

  def initialize foo, data
    @rows = data.size

  def get_number_cols

  def get_number_rows

  def get_value row, col

  def is_empty_cell row, col

  def get_attr row, col, kind Wx::BLACK, Wx::WHITE, Wx::NULL_FONT,

53ba108ecb05f9e1d67084cc51d2661e?d=identicon&s=25 Chloro F. (tony44)
on 2011-08-12 08:57

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

So the question becomes: how can I open a file dialog with a background
thread running, that accesses the serial interface?

Mario Steele (Guest)
on 2011-08-12 09:12
(Received via mailing list)
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
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
Threads, or Faux threads.  Meaning, that there is no secondary thread
actually created on the Operating System, but instead is handled
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.
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
Operating System thread.  When the background thread is called, and some
Function is currently being ran (Such as a GUI Dialog, or population of
wxGrid), the program will crash, trying to handle this, cause a re-entry
clause occurred when trying to execute the function, or rather, the
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
 The only suggestion that I can make, is that when the GUI needs
over the background worker threads, suspend the worker threads for the
duration of the GUI execution.  In other words, when showing a File
suspend the worker threads, show the dialog, once you get a response,
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
of interpreter, as it uses Native OS Threads for Ruby Threads.  But you
still need to be careful of worker threads, and GUI threads, just not
as insanely.


53ba108ecb05f9e1d67084cc51d2661e?d=identicon&s=25 Chloro F. (tony44)
on 2011-09-13 00:06
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.

This topic is locked and can not be replied to.