Description of problem: Ruby test suite segfaults presumably due to GCC 7. This is the backtrace: ``` - C level backtrace information ------------------------------------------- /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_print_backtrace+0x15) [0x7faabe1c1955] vm_dump.c:679 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_vm_bugreport+0x21c) [0x7faabe1c1b8c] vm_dump.c:988 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_bug_context+0xd4) [0x7faabe09bcb4] error.c:426 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(sigsegv+0x3e) [0x7faabe1574fe] signal.c:907 /lib64/libpthread.so.0 [0x7faabde08b50] /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(str_buf_cat+0x1c) [0x7faabe16d6dc] string.c:2571 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(w_nbyte+0x1a) [0x7faabe0d95fa] marshal.c:270 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(w_class+0x8a) [0x7faabe0da87a] marshal.c:281 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(w_object+0xb24) [0x7faabe0db434] marshal.c:733 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_marshal_dump_limited+0xe8) [0x7faabe0dbc58] marshal.c:1051 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_cfunc+0xf3) [0x7faabe1ac013] vm_insnhelper.c:1752 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec_core+0x46c) [0x7faabe1aed4c] insns.def:1066 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec+0x88) [0x7faabe1b52d8] vm.c:1712 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_yield+0x428) [0x7faabe1b83d8] vm.c:969 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_ary_each+0x3c) [0x7faabe0430cc] array.c:1824 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_cfunc+0xf3) [0x7faabe1ac013] vm_insnhelper.c:1752 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec_core+0x5ff) [0x7faabe1aeedf] insns.def:967 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec+0x88) [0x7faabe1b52d8] vm.c:1712 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_yield+0x428) [0x7faabe1b83d8] vm.c:969 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_ary_each+0x3c) [0x7faabe0430cc] array.c:1824 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_cfunc+0xf3) [0x7faabe1ac013] vm_insnhelper.c:1752 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_method+0xd3) [0x7faabe1ba073] vm_insnhelper.c:2291 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec_core+0x5ff) [0x7faabe1aeedf] insns.def:967 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec+0x88) [0x7faabe1b52d8] vm.c:1712 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_yield+0x428) [0x7faabe1b83d8] vm.c:969 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(rb_ensure+0xba) [0x7faabe0a1b6a] eval.c:926 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(dir_s_chdir+0xb4) [0x7faabe08be24] dir.c:1043 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_cfunc+0xf3) [0x7faabe1ac013] vm_insnhelper.c:1752 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_call_method+0xd3) [0x7faabe1ba073] vm_insnhelper.c:2291 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec_core+0x5ff) [0x7faabe1aeedf] insns.def:967 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(vm_exec+0x88) [0x7faabe1b52d8] vm.c:1712 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(ruby_exec_internal+0xad) [0x7faabe09f16d] eval.c:244 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(ruby_exec_node+0x1d) [0x7faabe0a0dad] eval.c:308 /builddir/build/BUILD/ruby-2.4.0/libruby.so.2.4.0(ruby_run_node+0x1e) [0x7faabe0a2d6e] eval.c:300 /builddir/build/BUILD/ruby-2.4.0/ruby(main+0x4b) [0x5610f1fe08cb] main.c:36 ``` Please see Koschei for the build logs: https://apps.fedoraproject.org/koschei/package/ruby?collection=f26 Version-Release number of selected component (if applicable): 7.0.1-0.3.fc26 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Ruby segfaults. Expected results: Ruby keeps working. Additional info:
Yes, we saw that in the test mass rebuild. But it was quite random failure, valgrind reported tons of unitialized memory uses in miniruby (and jump conditionalized on uninitialized memory uses), and also reports approximately same huge amount of those when miniruby is built with gcc 6. Therefore, we assume ruby it is ruby that is buggy (until proven otherwise).
True, it is some marshaling code, so it might be more sensitive to compiler changes. I'll report this upstream and will see. Thx for the feedback.
Note that when all of miniruby is built with -O0, then it doesn't crash, but trying to mix -O0 and -O2 objects the results are quite randomish, it isn't a single problematic *.o file or some small set of them that matter. So this really needs analysis from those who know the ruby source. It is possible it is a GCC bug, but we'd need far more details on what to look for (ideally reduced runtime testcase with details what is wrong).
Looks like applying https://github.com/ruby/ruby/commit/7c1b30a602ab109d8d5388d7dfb3c5b180ba24e1 makes ruby compile on rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=17563070 ref: https://bugs.ruby-lang.org/issues/13150 scratch build of 2.4.0-75.fc26 fails (again) https://koji.fedoraproject.org/koji/taskinfo?taskID=17564297
(In reply to Mamoru TASAKA from comment #4) Thx for pointing this out. I applied the patch and Ruby is building again.