Bug 1417590 - Ruby compiled with GCC 7.x+ segfaults
Summary: Ruby compiled with GCC 7.x+ segfaults
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1412274
TreeView+ depends on / blocked
 
Reported: 2017-01-30 11:21 UTC by Vít Ondruch
Modified: 2017-07-31 18:06 UTC (History)
12 users (show)

Fixed In Version: ruby-2.4.0-76.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-03 15:38:40 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Ruby 13168 None None None 2017-01-30 11:50:12 UTC

Description Vít Ondruch 2017-01-30 11:21:49 UTC
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:

Comment 1 Jakub Jelinek 2017-01-30 11:29:25 UTC
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).

Comment 2 Vít Ondruch 2017-01-30 11:39:48 UTC
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.

Comment 3 Jakub Jelinek 2017-01-30 11:53:19 UTC
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).

Comment 5 Vít Ondruch 2017-02-03 15:38:40 UTC
(In reply to Mamoru TASAKA from comment #4)
Thx for pointing this out. I applied the patch and Ruby is building again.


Note You need to log in before you can comment on or make changes to this bug.