Forum: wxRuby Segfault at exit when GC.stress = true

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.
2a11c93e55ef1e3bcca56c7f2d5e011d?d=identicon&s=25 unknown (Guest)
on 2014-02-04 02:36
(Received via mailing list)
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>'

-- 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 Hinton
L-3 Communications / Communication Systems West
2a11c93e55ef1e3bcca56c7f2d5e011d?d=identicon&s=25 unknown (Guest)
on 2014-02-05 22:07
(Received via mailing list)
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
06f6780c99d4a8dd71f2b474082ea9ce?d=identicon&s=25 Alex Fenton (Guest)
on 2014-02-06 12:20
(Received via mailing list)
Hi Ryan

On 05/02/14 22:01, 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).

This topic is locked and can not be replied to.