A bug in wxRuby. Segmentation fault in random situations

Desktop wxRuby
1

Hello,

I wrote an application in wxRuby:
ruby 1.8.6
wxruby 1.9.4 installed from gem
windows xp sp2

After several minutes of running it crashes with the following error:

"c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: [BUG]
Segmentation fault
ruby 1.8.6 (2007-03-13) [i386-mswin32]

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application’s support team for more information."

The biggest problem is that it is extremely difficult for me to find
the cause of the error because:

  1. I don’t get the normal exception so I cannot find the line of code
    which causes the error - the application merely crashes with the
    message cited above
  2. the crash occurs randomly in different situations, basicly when an
    event like pressing a button, opening a window, changing focus, etc.
    occurs (it doesn’t occur when I don’t touch the mouse/keyboard) - but
    I am unable to reproduce any of the crashes - when it crashes for
    instance after clicking button X, next time I can click button X a
    hundred of times and everything works perfectly until it crashes on
    pressing button Y, I think you know what I mean

The application has already about 160kb of source code and I have
completely no idea what causes the crash.
Anyway I think I should get an exception, not a crash so I assume this
is a bug in wxRuby.

I thought that maybe the crash occurs on first garbage collection but
it’s not the case - when I run GC manually somewhere in my application
(ObjectSpace.garbage_collect) it doesn’t crash.

What can I do in this situation?
I have an application which is almost finished but completely useless
because of those random crashes :frowning:
Can someone help me?
How can I debug the application to actually see the reason of the crash?

2

Hello Jacek,

Well, the first thing you can try, to see if it’s a Garbage Collection
problem, is to add to the top of your application GC.disable. Now, this
will cause increased memory usage by your program, cause objects will
not be
destroyed / recycled. This is just to see if this is truely a Garbage
Collection problem or not.

The next thing that is helpful for us for tracking down these problems,
is
some basic information about the program, what is it’s main purpose,
what Wx
classes are you implementing in your program, this would allow us to be
able
to trace where the problem may be occuring. You don’t have to list
every
single control you have created in the app, just a overview of controls,
like TextCtrl, StyledTextCtrl, Menu, Button, Grid, like that. This way
we
can also check and see if there’s already an open bug concerning the
segmentation fault due to a certian class.

Lastly, tracking down random crashes is very hard to track, even for us.
When a Segmentation Fault occurs, there is no “Rescue” mode for us to be
able to throw an Exception. (Atleast not to my knowledge, Maybe Alex or
Sean know something I don’t.) Basically, when random crashes occur, the
best thing we can suggest, is utilizing gdb, but that is only available
on
Linux and Mac OS X, so tracking down this kind of problem is very hard
to
trace on Windows XP.

Like I said, Alex or Sean may have something up their sleves, but for
now,
try doing what I suggested here, and give us a report on what you find
out,
and we’ll try to go from there.

Thanks,
Mario S.

3

Jacek Nowak wrote:

Hello,

I wrote an application in wxRuby:
ruby 1.8.6
wxruby 1.9.4 installed from gem
windows xp sp2

After several minutes of running it crashes with the following error:

"c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: [BUG]
Segmentation fault
ruby 1.8.6 (2007-03-13) [i386-mswin32]

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application’s support team for more information."

Hi, I’m experiencing exactly the same problem.
I’m using :

  • windows xp sp2
  • ruby-gtk2 binding (one click installer)
  • ruby 1.8.6 (last one click installer released)

My application is not really big, ~1800 lines and I can’t reproduce the
bug with linux.
For now the only way to fix my problem is to run manually the garbage
collector for time to time inside the application. If I don’t run the
garbage collector, my application ends up by crashing after some time
(could it be when garbage collecting is triggered?) or crashs when I
close it (when freeing memory?).

So I don’t think the problem comes from wxruby or gtk+, but we our
applications are running out of memory…

Good luck,
Lionel

4

Hi Jacek

Jacek Nowak wrote:

After several minutes of running it crashes with the following error:

"c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: [BUG]
Segmentation fault
ruby 1.8.6 (2007-03-13) [i386-mswin32]

THanks for the report, and I’m sorry that you’re running into this
crash. The top development priority for wxRuby at the moment is
identifying and fixing such bugs as remain - but as you say, isolating
them is not easy. I’ve got some detailed suggestions below which should
help, however.

A line number or triggering event will probably be spurious. As Mario
said, it’s very likely a garbage collection error in an unrelated object

  • The wxRuby SWIG bindings are either deleting an object still needed by
    wxWidgets, or trying to delete one wxWidgets has already disposed of.
    The trigger is just Ruby creating a new event object which happens to
    cause enough memory to have been allocated to force GC to run.

What can I do in this situation?
I have an application which is almost finished but completely useless
because of those random crashes :frowning:
Can someone help me?
How can I debug the application to actually see the reason of the crash?

Ouch - I feel your frustration…

There’s a few steps you can take which should help isolate it. Two are
pretty simple

  • Think if there’s a particular feature you added before which this
    crash didn’t occur
  • Check that the crash hasn’t been introduced in an upgrade to your
    wxRuby version (I hope not!)

The next step is to try to force a crash much closer in time to the code
that is causing it; this is not hard to try and often yields good
results.

There is a method gc_stress in Wx::App which is designed for this; it is
documented in lib/wx/classes/app.rb. If you call this method (typically
in on_init/run) it will force Ruby’s GC to run much more frequently -
exactly how often can be customised by passing a number of milliseconds.
1-5s might be a good start. Add this call, then run your application and
observe what you did shortly before a crash happened. Within a few runs
it may well be possible to identify what is causing the crash.

Things to look out for might be:

  • opening a new window of some sort
  • closing a particular kind of window or dialog
  • assigning some kind of Wx object to another in an event handler - eg
    adding an item to a list, or an attribute to a grid cell

Hopefully you can then pin it down to a particular Dialog, Frame or
piece of event handling code and can post that to us.

The last “gold standard” way is to use a compiled-code debugger.
Microsoft’s is available free (search for “microsoft debugger”). In
short, you use this by starting your app, then choosing “attach to
process” (F6) in the debugger and finding the ruby process. Then you
“run app” in the debugger (F5) and proceed to work with your wxRuby
application. When it crashes, the debugger will capture a lot of
information, including, most importantly, a stack trace of where in the
C++ code the crash actually occurred. This can be posted.

However, I’m not certain what results you’ll get with the debugger and
the wxRuby gem releases as these have much debugging information
stripped out to reduce the download file size. If you are able to
provide access to your source code I would be happy to try running it
under a debugger and debug build on Windows - contact me off-list.

I hope this helps - keep us posted
alex

5

Hi,

Thanks a lot for all your answers.
It’s a very nice support on this mailing list.

Here are my observations as for today (most are things Mario suggested
me to do as I had yet no time to do things suggested by Alex, so
expect another report in the next couple of days):

  1. I added GC.disable in the beginning of my application and it seems
    that it doesn’t crash right now.

  2. I installed my application on Linux (Ubuntu 7.04) and there the
    same random crashes occur (with GC enabled):

"/usr/lib/ruby/1.8/rubygems/custom_require.rb:27: [BUG] Segmentation
fault
ruby 1.8.5 (2006-08-25) [i486-linux]

Aborted (core dumped)"

  1. The same crashes occured with wxRuby 1.9.0 (in fact I was using
    1.9.0 and I upgraded to the newest version 1.9.4 a couple of days ago
    in order to find a solution for my crashes)

  2. The crash occurs sooner if I do a lot of “clicking” in my
    application (a lot of opening/closing windows or dialogs or more
    generally when a lot of events occur).

  3. The purpose of the program is to manage a shop (it logs
    transactions, prints receipts, prepares documents for tax purposes,
    etc).
    It’s a typical database client. It’s a MDI application.
    The most used control is ListCtrl (in LC_REPORT mode) - it’s used for
    displaying results of SQL queries.
    Other controls used:
    Button,TextCtrl,StaticText,MDIParentFrame,MDIChildFrame,
    Menu,MenuBar,ComboBox,Dialog,MessageDialog,
    BoxSizer,PrintData,Printer,Printout
    I hope I haven’t forgotten about something.
    (I’m also using mysql-ruby module but I don’t think it causes the error)

I will try to do what Alex suggested.
I don’t mind sending you the source code but the installation of my
application is a bit complicated as you must set up the MySQL
database, import data from an old CLIPPER database (in fact what I’m
doing is the rewrite of an old DOS application written in CLIPPER to
something cross-platform and more functional), etc.

Recently I found a way to reproduce this bug in one place of the
application so I will try to strip as much of the code as possible and
I will send you a piece of code easier to handle and debug.

Thanks again for all your help.
In a couple of days I will provide a more detailed report.

6

Jacek Nowak wrote:

  1. I installed my application on Linux (Ubuntu 7.04) and there the
    same random crashes occur (with GC enabled):

"/usr/lib/ruby/1.8/rubygems/custom_require.rb:27: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i486-linux]

Aborted (core dumped)"

If you have Linux available it might be easier to get started with a
debugger (gdb). Run it like this:

gdb --args ruby [script.rb]

At the gdb prompt, type ‘r’ to run the program
Then, when it crashes, type ‘whe’ to get a backtrace, which can be
copied and pasted to the list

  1. The crash occurs sooner if I do a lot of “clicking” in my
    application (a lot of opening/closing windows or dialogs or more
    generally when a lot of events occur).

Doing more events will create more objects, which will cause Ruby’s GC
to run sooner.

It’s a typical database client. It’s a MDI application.
The most used control is ListCtrl (in LC_REPORT mode) - it’s used for
displaying results of SQL queries.
Other controls used:
Button,TextCtrl,StaticText,MDIParentFrame,MDIChildFrame,
Menu,MenuBar,ComboBox,Dialog,MessageDialog,
BoxSizer,PrintData,Printer,Printout
There’s already some fixees in SVN to one or two of these classes, but
may well be something new
In a couple of days I will provide a more detailed report.

Great, look forward to it; thanks for your patience

alex

7

Then, when it crashes, type ‘whe’ to get a backtrace, which can be
copied and pasted to the list

Here you are:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211454640 (LWP 6540)]
0xb724e51c in GC_mark_wxWindow () from
/var/lib/gems/1.8/gems/wxruby-1.9.4-x86-linux/lib/wxruby2.so
(gdb) whe
#0 0xb724e51c in GC_mark_wxWindow () from
/var/lib/gems/1.8/gems/wxruby-1.9.4-x86-linux/lib/wxruby2.so
#1 0xb7ea0070 in ?? () from /usr/lib/libruby1.8.so.1.8
#2 0x084a9cf0 in ?? ()
#3 0x00016112 in ?? ()
#4 0x085b90e8 in ?? ()
#5 0xb7e82a25 in ?? () from /usr/lib/libruby1.8.so.1.8
#6 0x00016112 in ?? ()
#7 0x00000001 in ?? ()
#8 0xbfdb0938 in ?? ()
#9 0xbfdb0918 in ?? ()
#10 0xb7e9fad4 in ruby_stack_check () from /usr/lib/libruby1.8.so.1.8
#11 0xb6f1efda in wxRubyApp::mark_iterate () from
/var/lib/gems/1.8/gems/wxruby-1.9.4-x86-linux/lib/wxruby2.so
#12 0xb7e95bb8 in ?? () from /usr/lib/libruby1.8.so.1.8
#13 0xb418b8e8 in ?? ()
#14 0x00000004 in ?? ()
#15 0xb7ca79f4 in ?? ()
#16 0xb7e8ae18 in ?? () from /usr/lib/libruby1.8.so.1.8
#17 0x00000040 in ?? ()
#18 0x00000001 in ?? ()
#19 0x00000030 in ?? ()
#20 0xb7ca79f4 in ?? ()
#21 0xb418b8e8 in ?? ()
#22 0xb418b94c in ?? ()
#23 0x00000000 in ?? ()
(gdb)

8

Thanks Jacek,

It looks as though your libruby1.8.so.1.8 has been stripped of all
debugging
information. Which is often the practice of the Distro, to conserve
bandwidth and storage on public servers, where they host their
packages. Unfortunatly, for us, this leaves very little for us to
figure
out on where it is crashing specifically. Only thing I can tell from
this
debug output, is that ruby_stack_check() is being called, which is
checking
the stack of objects to see what is clear to be deleted/recycled, and
what
isn’t. Infact, it’s actually running through wxRuby’s objects at the
point
and time, simply case of wxRubyApp::mark_iterate() is being called.

To better understand what is going on, I would ask, that you uninstall
the
Ruby package, through your Distro’s Package Manager (Usually YUM for Red
Hat/Fedora, Synaptic for Mandrivia/Ubuntu, Portage for Gentoo, you get
the
idea), then download Ruby from
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p111.tar.gz, and follow
the
following instructions:

Bring up a Terminal (Terminal/Konsole/rxte/etc/etc)
cd ~/directory_where/you_have_ruby/downloaded_to
tar -xzf ruby-1.8.6-p111.tar.gz
cd ruby-1.8.6-p111
./configure --prefix=/usr
make
sudo make install

Ofcourse, replace ~/directory_where/you_have_ruby/downloaded_to to where
you
actually downloaded the file to. Generally, that’s ~/Desktop on most
systems, sometimes that is just ~ (Which is your home directory) Once
you
compiled and installed Ruby through the instructions up above, then try
running gdb against your application, and type in whe. You will find
that
you’ll get a lot more information from it, instead of a lot of lines
that
have ?? in them.

Already, from your report that GC.disable works for the application, and
prevents the segmentation fault, means that it is a Garbage Collection
problem. So, now we just need to figure out where in this process, our
bug
lies in. Also, if your brave enough to compile from SVN for wxRuby, and
test out the SVN code against your application, to see if the bug has
been
fixed or not, make sure you have SVN installed, and follow these
instructions:

Download wxGTK from
http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.8.7.tar.gz
Utilize the same instructions above for cd and tar, then utilize the
following command to build wxGTK.

cd wxGTK-2.8.7/build
…/configure --disable-shared --with-gtk --enable-monolithic
–enable-unicode --disable-debug --enable-catch_segvs
–enable-graphics_ctx

–enable-mediactrl --with-opengl --with-libjpeg=builtin
–with-libpng=builtin
–with-libtiff=builtin --with-zlib=builtin --with-expat=builtin
–enable-gui

–enable-xrc --enable-mdi --enable-gif
–enable-pcx --enable-iff --enable-pnm --enable-xpm
make
sudo make install
cd contrib/src/stc
make
sudo make install

Then ensure that you have SWIG 1.3.31, which can be downloaded from:
http://prdownloads.sourceforge.net/swig/swig-1.3.31.tar.gz

Same procedure as before
cd swig-1.3.31
./configure --prefix=/usr
make
sudo make install

And ensure that you have Rake installed. If you have Ruby Gems
installed,
which it looks like you do, simply run:
sudo gem install rake

Once you have all of this done, simply run SVN like so:

svn co svn://rubyforge.org/var/svn/wxruby/trunk/wxruby2

Then run:
cd wxruby2
rake
sudo rake install

With luck, all of these instructions, will give you a Fresh SVN Copy of
wxRuby to test out.

Quite a few instructions, but this will get you well on your way to
helping
us test this stuff out, so we can get wxRuby to it’s true 2.0 release
mark.

L8ers,

Mario S.

9

Hi,

I have a lot of trouble trying to find out what exactly causes the bug.
Generally it seems that the more code I remove from my application,
the more rarely the crash happens.

What I did:

  1. First I removed all calls of method “destroy” in dialogs.
    Normally my code for displaying dialogs was everywhere like that:
    d = SomeDialog.new(self,-1,“title”,some_arguments)
    d.show_modal
    d.destroy

I removed all calls to “destroy” and it seems that now my
application crashes less often (at least it doesn’t crash in the place
where it always crashed before). But still it crashes from time to
time.

  1. I managed to create a small chunk of code which always crashes just
    after closing of MDIChildFrame but it crashes only when gc_stress is
    set to 1ms or something near that.
    If I set it to 1s or more I’m not able to trigger the crash so I don’t
    know if this is the issue of GC called too often or the problem with
    the code.
    I am sending you the code below:

============== BEGIN OF CODE:

#!/usr/bin/env ruby

require ‘rubygems’
require ‘wx’

include Wx

class KatalogTowarowFrame < Wx::MDIChildFrame
def initialize(parent,id,title)
super(parent,id,title)

button1 = Button.new(self,-1,"aaaa")
button2 = Button.new(self,-1,"bbbb")

sizer1 = BoxSizer.new(HORIZONTAL)
sizer1.add(button1,1,GROW,2)
sizer1.add(button2,1,GROW,2)

set_sizer(sizer1)

end
end

class MainFrame < Wx::MDIParentFrame
def initialize
super(nil, -1, “Application that crashes”, DEFAULT_POSITION,
Wx::Size.new(800,600),
DEFAULT_FRAME_STYLE | VSCROLL | HSCROLL | FRAME_NO_WINDOW_MENU)
menu1 = Menu.new
menu1.append(5000, “test test”,“test test”)

    menubar = MenuBar.new()
    menubar.append(menu1,"fdlgfdgfdgddffgd")

    set_menu_bar(menubar)

    create_status_bar

    evt_menu(5000) {|event| on_a(event)}
end

def on_a(event)
win = KatalogTowarowFrame.new(self,-1,“Kartoteka towarow”)
win.show
win.set_focus
end
end

class Aplikacja < Wx::App
def on_init
gc_stress
mainframe = MainFrame.new
mainframe.set_title(“abc”)
mainframe.show()
end
end

Aplikacja.new.main_loop

============== END OF CODE

10

Hi Jacek

Thanks for posting more details. I’ve just fixed a bug in SVN which fits
with the code and symptom you supplied. I tested your code on OS X and
it now doesn’t crash after the MDI child is closed with HEAD, though I
can reproduce the crash with the 1.9.4 rubygem.

So I am hopeful that this will be resolved by the next release which
should be soon, but if you are able please test with the latest source
from SVN.

Jacek Nowak wrote:

I have a lot of trouble trying to find out what exactly causes the bug.

So did I … this bug has been vexing me for more than a month and was a
git to track down.

  1. First I removed all calls of method “destroy” in dialogs.
    Definitely stick with this.
    But still it crashes from time to time.

The trigger was the destruction of a Frame or Dialog containing a Sizer;
after this it would crash on the next GC run. So it would seem sporadic,
in the pattern you gave.

cheers
alex

11

Jacek Nowak wrote:

Then, when it crashes, type ‘whe’ to get a backtrace, which can be
copied and pasted to the list

Here you are:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211454640 (LWP 6540)]
0xb724e51c in GC_mark_wxWindow () from

Thanks for this. As Mario says, this confirms that it’s a GC collection
issue. But I would suggest that instead of putting time into installing
a build from source, that you first pursue trying to isolate using
gc_stress.

It just happens that in this case, a full debugging backtrace wouldn’t
help identify exactly which Window is causing the problem.

cheers
alex

12

Hi Alex,

Thanks for all your help.
I am trying to compile the latest source from svn.
When I run “rake” everything seems to compile well but after 2 or 3
minutes I get the following error:

GLCanvas.cpp
.\src/GLCanvas.h(19) : error C2504: ‘wxGLCanvas’ : base class undefined
.\src/GLCanvas.h(23) : error C2629: unexpected ‘class
SwigDirector_wxGLCanvas (’
.\src/GLCanvas.h(23) : error C2238: unexpected token(s) preceding ‘;’
.\src/GLCanvas.h(24) : error C2629: unexpected ‘class
SwigDirector_wxGLCanvas (’
.\src/GLCanvas.h(24) : error C2238: unexpected token(s) preceding ‘;’
src/GLCanvas.cpp(2393) : error C2614: ‘SwigDirector_wxGLCanvas’ :
illegal member initialization: ‘wxGLCanvas’ is not a base or member
src/GLCanvas.cpp(2399) : error C2061: syntax error : identifier
‘wxGLCanvas’
src/GLCanvas.cpp(2399) : error C2511:
‘SwigDirector_wxGLCanvas::SwigDirector_wxGLCanvas’ : overloaded member
function ‘void (unsigned long,class wxWindow *)’ not found in
‘SwigDirector_wxGLCanvas’
.\src/GLCanvas.h(19) : see declaration of
‘SwigDirector_wxGLCanvas’
src/GLCanvas.cpp(4019) : fatal error C1004: unexpected end of file found

I downloaded the latest source from svn.
I am using:
wxWidgets 2.8.7
swigwin-1.3.34
rake-0.8.1
windows xp sp2
msvc++ 6.0

(btw - in the wiki :
http://wxruby.rubyforge.org/wiki/wiki.pl?InstallingFromSource it is
written that I should use swig-1.3.31 but when I tried to compile with
this version rake gave me an error that I should use 1.3.34)

13

Hi Jacek

Jacek Nowak wrote:

I am trying to compile the latest source from svn.
When I run “rake” everything seems to compile well but after 2 or 3
minutes I get the following error:

GLCanvas.cpp
.\src/GLCanvas.h(19) : error C2504: ‘wxGLCanvas’ : base class undefined

I’ve always skipped GLCanvas on my Windows build, so I don’t know
exactly what’s up. I’m guessing some missing library i.e. opengl. Sean
makes the release windows build so may have some ideas.

If you don’t need GLCanvas, probably easiest just to avoid it.

Method 1) This should force wxRuby to skip this class, but you’ll need
to remember this argument every time, or set an environment variable.
Delete src/GLCanvas.cpp then build wxRuby with:

rake WXRUBY_EXCLUDED=GLCanvas

Method 2) Rebuild wxWidgets without the USE_OPENGL argument to nmake.
Then wxRuby should notice that class isn’t supported and skip it.

(btw - in the wiki :
http://wxruby.rubyforge.org/wiki/wiki.pl?InstallingFromSource it is
written that I should use swig-1.3.31 but when I tried to compile with
this version rake gave me an error that I should use 1.3.34)

Yeah, we upgraded to the latest SWIG releases in the dev cycle as they
have ruby fixes pertinent to wxRuby. The code was already checking, but
I’ve updated the wiki to reflect this. Thanks

alex

14

Jacek Nowak wrote:

Hi!

I installed the latest version from svn and there are no crashes
anymore! :slight_smile:
I have tested my app extensively with gc_stress and now it works fine.

Do you know if this bug is fixed for the wxruby (1.9.7) I’m running the
bigdemo.rb in 2 different machines with win XP SP2 obtaining the
following error:

C:\ruby\lib\ruby\gems\1.8\gems\wxruby-1.9.7-x86-mswin32-60\samples\bigdemo>ruby
bigdemo.rb
bigdemo.rb:823: [BUG] Segmentation fault
ruby 1.8.6 (2007-09-24) [i386-mswin32]

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application’s support team for more information.

As described by Jacek Nowak:

the crash occurs randomly in different situations, basicly when an
event like pressing a button, opening a window, changing focus, etc.
occurs (it doesn’t occur when I don’t touch the mouse/keyboard)

Thanks in advance.

15

Leonardo Otero wrote:

This application has requested the Runtime to terminate it in an unusual

Thanks for the report. The bug that Jacek described was fixed in 1.9.7
so this must be something else. Could you be more specific about where
the crash occurs (eg which part of bigdemo.rb is running). We will need
to run it under a debugger to pin down the problem.

alex

16

Hi!

I installed the latest version from svn and there are no crashes
anymore! :slight_smile:
I have tested my app extensively with gc_stress and now it works fine.

Thanks a lot to Alex and Mario for your support and to all developers
of wxruby for all your work.
You are doing a really great job!
Wxruby is very nice, definitely the best solution for writing GUI apps
in ruby.
I am expecting with impatience a stable 2.0 release. I hope there are
aren’t many bugs left.

So I will continue writing my app in wxruby, if I find any more
problems I will let you know.