Segfault at exit when GC.stress = true

The following minimal application gives a segfault at exit when the
GC.stress line is uncommented. Any clues on how to debug this? Thanks!

require ‘rubygems’
rescue LoadError
require ‘wx’

GC.stress = true

class ClipError2 < Wx::Frame
def initialize(parent)
end do
frame =

Here are the details of my environment.

$ uname -a
Linux hostname 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
$ ruby --version
ruby 1.9.3p448 (2013-06-27) [x86_64-linux]
$ wx-config --list

Default config is gtk2-unicode-release-2.8

Default config will be used for output

wxRuby is built from source from the wxruby_2_0_stable branch. Let me
know if there is any more information I can provide.

Here are the first few lines of the stack trace.

$ ruby ~/transfer/clip_error2.rb
/user/rhinton/local/lib/ruby/site_ruby/1.9.1/wx/classes/app.rb:16: [BUG]
Segmentation fault
ruby 1.9.3p448 (2013-06-27) [x86_64-linux]

– Control frame information

c:0006 p:---- s:0017 b:0017 l:000016 d:000016 CFUNC :on_run
c:0005 p:---- s:0015 b:0015 l:000014 d:000014 CFUNC :main_loop
c:0004 p:0053 s:0012 b:0012 l:000011 d:000011 METHOD
c:0003 p:0080 s:0006 b:0006 l:0000f8 d:002448 EVAL
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0000f8 d:0000f8 TOP

– Ruby level backtrace information

/user/rhinton/transfer/clip_error2.rb:15:in <main>' /user/rhinton/local/lib/ruby/site_ruby/1.9.1/wx/classes/app.rb:16:inrun’
main_loop' /user/rhinton/local/lib/ruby/site_ruby/1.9.1/wx/classes/app.rb:16:inon_run’

– C level backtrace information

ruby() [0x525555]
ruby() [0x569ba6]
ruby(rb_bug+0xb3) [0x569d13]
ruby() [0x4b1759]
/lib64/ [0x3632e0f500]

– Other runtime information

  • Loaded script: /user/rhinton/transfer/clip_error2.rb

Ryan H.
L-3 Communications / Communication Systems West
[email protected]

I ran valgrind and got a little more (possibly useful) information.
Right before the crach, I get the following output from valgrind.

==2970== Jump to the invalid address stated on the next line
==2970== at 0x0: ???
==2970== by 0xBDB17EB: GC_mark_wxFrame(void*) (wx.cpp:2547)
==2970== by 0x421F29: gc_marks (gc.c:1969)
==2970== by 0x422516: garbage_collect (gc.c:2602)
==2970== by 0x422BC8: rb_newobj (gc.c:1200)
==2970== by 0x42319D: rb_data_object_alloc (gc.c:1244)
==2970== by 0xBDB18E5: wxRuby_WrapWxEventInRuby(wxEvent*)
==2970== by 0xB8CCFF2: SwigDirector_App::FilterEvent(wxEvent&)
==2970== by 0x3633AE4923: wxEvtHandler::ProcessEvent(wxEvent&) (in
==2970== by 0xDB9E90E: wxWindowBase::SendDestroyEvent() (in
==2970== by 0xDAD217B: wxWindow::~wxWindow() (in
==2970== by 0xB9F9E58: SwigDirector_wxFrame::~SwigDirector_wxFrame()
==2970== Address 0x0 is not stack’d, malloc’d or (recently) free’d

Is there any more useful information I can provide?

  • Ryan

Hi Ryan

On 05/02/14 22:01, [email protected] wrote:

I ran valgrind and got a little more (possibly useful) information.
Right before the crach, I get the following output from valgrind.

Thanks for your posts and debugging. I don’t want to dampen your
enthusiasm, but there is no-one maintaining or developing this wxRuby at
present There might be other ports you could look into, or use this one

If you want to work on it yourself, you need a debug build of wxRuby,
plus gdb or similar (valgrind looks to be pointing you in the right

wxRuby has a set of procedures for reconciling Ruby and Wx/C++ memory
management - when Ruby’s garbage collection should, and should not,
delete Wx objects and so on. These are defined on a per-Wx-class basis
in the swig files (swig/classes/.i), with generic strategies in
swig/memory_management, and some per-class routines called mark_Wx
which protect owned objects (e.g. Sizers belonging to Frames).