Reproducable FileDialog crashes on Win

Desktop wxRuby
1

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.

Thanks for any help,
Tony

2

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
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

3

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

4

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

5

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