Getting gdb backtrace from ruby exception

Ruby
1

Hi

I’m working on a C extension and somewhere in itsomething is raising a
NoMethodError. The exception is reported with the line of ruby code that
triggered the bad call in the C extension.

As the C code is large and complex (it’s a big SWIG project), I’m having
trouble finding the problem in the C code. I would use gdb or
Microsoft’s debugger to look at the stack if it was a C error - but when
a Ruby exception is raised, the process exits and there’s no stack to
inspect.

Ruby’s debugger isn’t helpful because it only knows about ruby written
in ruby.

Is there any way I can get at the C stack at the point of ruby ‘raise’
from a C extension?

Thanks
alex

2

On 7/12/07, Alex F. [email protected] wrote:

inspect.

Ruby’s debugger isn’t helpful because it only knows about ruby written
in ruby.

Is there any way I can get at the C stack at the point of ruby ‘raise’
from a C extension?

Thanks
alex

There was a way how to run ruby under gdb with the ability to debug at
“ruby level” while still having the “C view” at hand.

http://eigenclass.org/hiki.rb?ruby+live+process+introspection
http://weblog.jamisbuck.org/2006/9/25/gdb-wrapper-for-ruby
http://redhanded.hobix.com/inspect/theRubyGdbArmsRaceNowAtAStandoff.html

J.

3

Hi,

i don’t know how to build stack traces, but you can start ruby in gdb.

first call gdb with ruby as argument. On liux it looks like:

det@datengrab:~/Desktop$ gdb /usr/bin/ruby

and then in gdb start your ruby program with “run”

(gdb) run ./my-prg.rb

Cheers
detlef

Am Donnerstag, den 12.07.2007, 23:10 +0900 schrieb Alex F.:

4

On Jul 12, 2007, at 8:10 AM, Alex F. wrote:

no stack to inspect.

Ruby’s debugger isn’t helpful because it only knows about ruby
written in ruby.

Is there any way I can get at the C stack at the point of ruby
‘raise’ from a C extension?

Thanks
alex

cfp:~ > cat core.rb
BEGIN{ at_exit{ Process.kill ‘SIGSEGV’, Process.pid if $! } }

cfp:~ > cat a.rb
#! /usr/bin/env ruby
require ‘core’
p 42
cfp:~ > ruby a.rb
42

cfp:~ > cat b.rb
#! /usr/bin/env ruby
require ‘core’
raise

cfp:~ > ruby b.rb
./core.rb:1: [BUG] Segmentation fault
ruby 1.8.6 (2007-03-13) [i686-darwin8.9.1]

Abort trap (core dumped)

-a

5

Jano S. wrote:

On 7/12/07, Alex F. [email protected] wrote:

Is there any way I can get at the C stack at the point of ruby ‘raise’
from a C extension?

There was a way how to run ruby under gdb with the ability to debug at
“ruby level” while still having the “C view” at hand.

eigenclass.org
Buckblog: GDB wrapper for Ruby
http://redhanded.hobix.com/inspect/theRubyGdbArmsRaceNowAtAStandoff.html

Thanks for the pointer - that’s really interesting stuff. I got round it
a bit more prosaically by simply setting a breakpoint in gdb where ruby
calls the exception raising class

(gdb) b rb_exc_raise
Breakpoint 1, rb_exc_raise (mesg=3057353380) at eval.c:4583
4583 rb_longjmp(TAG_RAISE, mesg);
(gdb) whe

… tasty stacktrace

cheers
alex

6

ara.t.howard wrote:

having trouble finding the problem in the C code. I would use gdb or
Thanks
require ‘core’

cfp:~ > ruby b.rb
./core.rb:1: [BUG] Segmentation fault
ruby 1.8.6 (2007-03-13) [i686-darwin8.9.1]

Abort trap (core dumped)

Doesn’t that only give you the C stack at the time the ruby process
exits, not at the time the exception is raised?

7

On Jul 12, 2007, at 4:25 PM, Joel VanderWerf wrote:

Doesn’t that only give you the C stack at the time the ruby process
exits, not at the time the exception is raised?

yeah - it’s a short leap though…

-a