Ruby

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.