Segfault at exit when GC.stress = true


#1

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

begin
require ‘rubygems’
rescue LoadError
end
require ‘wx’

GC.stress = true

class ClipError2 < Wx::Frame
def initialize(parent)
super
end
end

Wx::App.run do
frame = ClipError2.new(nil)
frame.show
end

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
/user/rhinton/local/lib/ruby/site_ruby/1.9.1/wx/classes/app.rb:16
c:0003 p:0080 s:0006 b:0006 l:0000f8 d:002448 EVAL
/user/rhinton/transfer/clip_error2.rb:15
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’
/user/rhinton/local/lib/ruby/site_ruby/1.9.1/wx/classes/app.rb:16:in
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/libpthread.so.0() [0x3632e0f500]

– Other runtime information

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

Ryan H.
L-3 Communications / Communication Systems West
removed_email_address@domain.invalid


#2

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*)
(wx.cpp:2390)
==2970== by 0xB8CCFF2: SwigDirector_App::FilterEvent(wxEvent&)
(App.cpp:2531)
==2970== by 0x3633AE4923: wxEvtHandler::ProcessEvent(wxEvent&) (in
/usr/lib/libwx_baseu-2.8.so.0.8.0)
==2970== by 0xDB9E90E: wxWindowBase::SendDestroyEvent() (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.8.0)
==2970== by 0xDAD217B: wxWindow::~wxWindow() (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.8.0)
==2970== by 0xB9F9E58: SwigDirector_wxFrame::~SwigDirector_wxFrame()
(Frame.cpp:2358)
==2970== Address 0x0 is not stack’d, malloc’d or (recently) free’d

Is there any more useful information I can provide?

  • Ryan

#3

Hi Ryan

On 05/02/14 22:01, removed_email_address@domain.invalid 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
as-is.

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
direction).

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

cheers
alex