Feature #20002: Print C-level backtrace on uncaught Ruby exceptions

• Status: Open
• Assignee: -
• Target version: -

[osyoyu (Daisuke Aritomo)]

When a uncaught Ruby exception occurs, the Ruby-level backtrace is printed.
While this information is valuable for debugging Ruby code, this isn't necessarily the case when developing C extensions, since this message has no information about C code.

In this example, the printed message only tells us that something is wrong inside will_raise.
There are not much ways to debug further; the programmer must guess which Ruby API call is causing the exception.
A C-level backtrace which includes the VALUE x = NUM2INT(rb_str_new_cstr("1")); line would be very helpful here.

% ruby main.rb
main.rb:9:in `will_raise': no implicit conversion of String into Integer (TypeError)

  will_raise
  ^^^^^^^^^^
        from main.rb:9:in `bar'
        from main.rb:4:in `foo'
        from main.rb:12:in `<main>

require_relative "./ext"

def foo
  bar
end

def bar
  will_raise
end

foo

#include <ruby/ruby.h>

VALUE will_raise(VALUE self) {
  // Do many things

  // There is no information leading to this line in the printed message
  VALUE x = NUM2INT(rb_str_new_cstr("1")); // no implicit conversion of String into Integer (TypeError)
  return Qtrue;
}

void Init_ext(void) {
  rb_define_method(rb_mKernel, "will_raise", will_raise, 0);
}

I'm imagining something similar to the segfault report.
In this case, it is clear that some code caused a SIGSEGV in ext.c:12 (which is int *p = NULL; *p = 1;).

-- C level backtrace information -------------------------------------------
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_print_backtrace+0x14) [0x55dd24893174] /home/osyoyu/ruby/build/../vm_dump.c:812
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_vm_bugreport) /home/osyoyu/ruby/build/../vm_dump.c:1140
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_bug_for_fatal_signal+0x14c) [0x55dd24a064cc] /home/osyoyu/ruby/build/../error.c:1065
/home/osyoyu/.rbenv/versions/master/bin/ruby(sigsegv+0x51) [0x55dd24801c01] /home/osyoyu/ruby/build/../signal.c:920
/usr/lib/libc.so.6(0x7f6926558710) [0x7f6926558710]
/home/osyoyu/ruby-bug/ext.so(will_segv+0x14) [0x7f69264fc244] /home/osyoyu/ruby-bug/ext.c:12
/home/osyoyu/ruby-bug/ext.so(will_segv) (null):0
/home/osyoyu/.rbenv/versions/master/bin/ruby(vm_call_cfunc_with_frame_+0xf4) [0x55dd24885d64] ../vm_insnhelper.c:3477
/home/osyoyu/.rbenv/versions/master/bin/ruby(vm_sendish+0xdd) [0x55dd2486aee1] ../vm_insnhelper.c:5555
/home/osyoyu/.rbenv/versions/master/bin/ruby(vm_exec_core) ../insns.def:835
ruby(vm_exec_loop+0x0) [0x55dd24867c52]
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_vm_exec) /home/osyoyu/ruby/build/../vm.c:2420
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_ec_exec_node+0x2b) [0x55dd246e9fab] /home/osyoyu/ruby/build/../eval.c:287
/home/osyoyu/.rbenv/versions/master/bin/ruby(ruby_run_node) /home/osyoyu/ruby/build/../eval.c:328
/home/osyoyu/.rbenv/versions/master/bin/ruby(rb_main+0x1c) [0x55dd246e7a85] /home/osyoyu/ruby/build/../main.c:39
/home/osyoyu/.rbenv/versions/master/bin/ruby(main) /home/osyoyu/ruby/build/../main.c:58
/usr/lib/libc.so.6(0x7f6926541cd0) [0x7f6926541cd0]
/usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f6926541d8a]
[0x55dd246e7935]

As most Ruby users might not be interested in C-level information, this behavior could be made optional through startup options or environment variables.

[byroot (Jean Boussier)]

Maybe you already know, but when debugging a C extension you can trigger a crash report with rb_bug("message").

[osyoyu (Daisuke Aritomo)]

byroot (Jean Boussier) wrote in #note-1:

Maybe you already know, but when debugging a C extension you can trigger a crash report with rb_bug("message").

Yes, but the problem is that it is difficult to know where the exception is raised (which would be a good place to insert a rb_bug() call).
(I'm finding rb_bug() to be an assert-ish function to be called in unlikely situations, but I might be missing a point here)