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

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!


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:in
`run'
/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:in
`on_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 Hinton
L-3 Communications / Communication Systems West
ryan.w.hinton@L-3com.com
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*)
(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
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, ryan.w.hinton@L-3com.com 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
This topic is locked and can not be replied to.