Bug #14714: Ruby 2.5.1 Segmentation Fault in GC

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.6.0preview2 (2018-05-31 trunk 63539) [x86_64-darwin18]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[obromios (Chris Drane)]

I am using Ruby 2.5.1, and running ruby on rails 5.1.4 with rspec-rails 3.7.2 and capybara 3.0.2.

When I run my feature tests, i.e. rspec spec/features, I get a segmentation fault. When I found the test in which the fault is occurring, and run that test by itself, then the fault does not appear. If I make the offending test pending,and run rspec spec/features again, then the fault still occurs but in another test. Accordingly, I cannot give you the exact code that is causing the fault.

I have attached the crash report log file.

[obromios (Chris Drane)]

I have reverted to ruby 2.4.4 and done rspec/spec/features and the problem does not occur, to this increases the probability that it is a ruby 2.5.1 problem.

[nobu (Nobuyoshi Nakada)]

As it occurs in GC, it may reproduce with a few test by setting GC.stress to true.

[renchap (Renaud Chaput)]

• File ruby-bug-14714_2018-04-30-150948.crash ruby-bug-14714_2018-04-30-150948.crash added

I think I am seeing a similar bug.

My test suite (Rails system tests, using Minitest and Capybara) is crashing on MacOS when using Ruby 2.5.1.
It is not happening with MRI 2.4.4, or on Linux (containers on Circle CI) using 2.5.1.

I first suspected a bug with ruby-vips but as I can not reproduce it with 2.4.4, I think this is a bug in MRI (ruby-vips issue for reference: https://github.com/jcupitt/ruby-vips/issues/174).

ruby-vips is used to resize images using libvips (via ffi). When I switch to another way of resizing (using MiniMagick — which shells out to ImageMagick), the segfault does not occur. I think it happens because when using ruby-vips the resize is handled inside the MRI process and more memory is used.

The crash does not always happen, about 30% of the time the test suite finished. It sometimes crashes while resizing an image, but it sometimes also crashes later, in a test without any ruby-vips calls. The stack trace is always the same, and related to GC.

I tried to reproduce the problem by isolating my image resizing code and calling it a few thousand times on the same images as my test, without success. Running my app full test suite on 2.5.1 on a mac is the only way to reproduce it.
I tried to enable GC.stress = true at the start of the test suite but as the test suite uses a full-featured Rails app, launches a headless browser, ..., it is far too slow and I can not even get Rails to start.

[renchap (Renaud Chaput)]

I also tried to isolate my vips-related code in a new Ruby program, and ran it 100 times with GC.stress = true, without being able to reproduce.

[obromios (Chris Drane)]

I tried putting GC.stress = true in the rails_helper file, and after 4.5 hours, no test has been completed, so this is too slow to be practicable for my machine.

I am not using ruby-vips.

[renchap (Renaud Chaput)]

• ruby -v set to ruby 2.6.0preview2 (2018-05-31 trunk 63539) [x86_64-darwin18]

I just tested with 2.5.2 and 2.6.0-preview2 and I can still reproduce this when running my tests.

This still happens in GC:

-- C level backtrace information -------------------------------------------
0   ruby                                0x00000001026a3ae7 rb_vm_bugreport + 135
1   ruby                                0x000000010250cd43 rb_bug_context + 467
2   ruby                                0x0000000102612951 sigsegv + 81
3   libsystem_platform.dylib            0x00007fff6caf7b3d _sigtramp + 29
4   ruby                                0x00000001025274c3 rb_gc_mark_machine_stack + 99
5   ruby                                0x000000010269275b rb_execution_context_mark + 171
6   ruby                                0x00000001024f3ceb cont_mark + 27
7   ruby                                0x0000000102531391 gc_start + 2529
8   ruby                                0x00000001025306bc newobj_slowpath + 1324
9   ruby                                0x0000000102530164 newobj_slowpath_wb_protected + 20
10  ruby                                0x0000000102629e5d rb_str_resurrect + 61
11  ruby                                0x000000010262dae3 rb_str_concat_literals + 195
12  ruby                                0x0000000102684ebb vm_exec_core + 31675
13  ruby                                0x0000000102691af8 vm_exec + 2600
14  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
15  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
16  ruby                                0x000000010249b8a6 rb_ary_collect + 246
17  ruby                                0x0000000102696e3b vm_call_cfunc + 299
18  ruby                                0x000000010267ffc0 vm_exec_core + 11456
19  ruby                                0x0000000102691af8 vm_exec + 2600
20  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
21  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
22  ruby                                0x000000010249b8a6 rb_ary_collect + 246
23  ruby                                0x0000000102696e3b vm_call_cfunc + 299
24  ruby                                0x000000010267ffc0 vm_exec_core + 11456
25  ruby                                0x0000000102691af8 vm_exec + 2600
26  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
27  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
28  ruby                                0x000000010249b8a6 rb_ary_collect + 246
29  ruby                                0x0000000102696e3b vm_call_cfunc + 299
30  ruby                                0x000000010267ffc0 vm_exec_core + 11456
31  ruby                                0x0000000102691af8 vm_exec + 2600
32  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
33  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
34  ruby                                0x000000010249b8a6 rb_ary_collect + 246
35  ruby                                0x0000000102696e3b vm_call_cfunc + 299
36  ruby                                0x000000010267ffc0 vm_exec_core + 11456
37  ruby                                0x0000000102691af8 vm_exec + 2600
38  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
39  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
40  ruby                                0x000000010249b8a6 rb_ary_collect + 246
41  ruby                                0x0000000102696e3b vm_call_cfunc + 299
42  ruby                                0x000000010267ffc0 vm_exec_core + 11456
43  ruby                                0x0000000102691af8 vm_exec + 2600
44  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
45  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
46  ruby                                0x000000010249b8a6 rb_ary_collect + 246
47  ruby                                0x0000000102696e3b vm_call_cfunc + 299
48  ruby                                0x000000010267ffc0 vm_exec_core + 11456
49  ruby                                0x0000000102691af8 vm_exec + 2600
50  ruby                                0x000000010269f8ec invoke_iseq_block_from_c + 1084
51  ruby                                0x0000000102697693 vm_call_bmethod + 435
52  ruby                                0x0000000102697f02 vm_call_opt_send + 626
53  ruby                                0x000000010267ffc0 vm_exec_core + 11456
54  ruby                                0x0000000102691af8 vm_exec + 2600
55  ruby                                0x000000010269f8ec invoke_iseq_block_from_c + 1084
56  ruby                                0x0000000102697693 vm_call_bmethod + 435
57  ruby                                0x0000000102680ed9 vm_exec_core + 15321
58  ruby                                0x0000000102691af8 vm_exec + 2600
59  ruby                                0x000000010269f8ec invoke_iseq_block_from_c + 1084
60  ruby                                0x0000000102697693 vm_call_bmethod + 435
61  ruby                                0x000000010267ffc0 vm_exec_core + 11456
62  ruby                                0x0000000102691af8 vm_exec + 2600
63  ruby                                0x000000010269f8ec invoke_iseq_block_from_c + 1084
64  ruby                                0x0000000102697693 vm_call_bmethod + 435
65  ruby                                0x0000000102697f02 vm_call_opt_send + 626
66  ruby                                0x0000000102680ed9 vm_exec_core + 15321
67  ruby                                0x0000000102691af8 vm_exec + 2600
68  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
69  ruby                                0x000000010268be8e rb_yield + 158
70  ruby                                0x0000000102495f49 rb_ary_each + 57
71  ruby                                0x0000000102696e3b vm_call_cfunc + 299
72  ruby                                0x000000010267ffc0 vm_exec_core + 11456
73  ruby                                0x0000000102691af8 vm_exec + 2600
74  ruby                                0x000000010269f26e invoke_block_from_c_bh + 398
75  ruby                                0x000000010268c21e rb_yield_force_blockarg + 94
76  ruby                                0x000000010249b8a6 rb_ary_collect + 246
77  ruby                                0x0000000102696e3b vm_call_cfunc + 299
78  ruby                                0x000000010267ffc0 vm_exec_core + 11456
79  ruby                                0x0000000102691af8 vm_exec + 2600
80  ruby                                0x000000010268fd03 rb_vm_invoke_proc + 451
81  ruby                                0x00000001025ba8e2 rb_proc_call + 82
82  ruby                                0x0000000102516813 rb_exec_end_proc + 355
83  ruby                                0x0000000102516d95 ruby_finalize_0 + 133
84  ruby                                0x0000000102516edb ruby_cleanup + 299
85  ruby                                0x00000001025171af ruby_run_node + 63
86  ruby                                0x0000000102493203 main + 99

[renchap (Renaud Chaput)]

• Subject changed from Ruby 2.5.1 Segmentation Fault to Ruby 2.5.1 Segmentation Fault in GC

[wanabe (_ wanabe)]

I think it is related to (or same as) https://bugs.ruby-lang.org/issues/14561.
Because (1) all SEGV is on macOS and (2) all crash points are in rb_execution_context_mark().
But this is merely speculation and weak conclusion.

[renchap (Renaud Chaput)]

I tried to run my test suite (the only thing that I found triggering the crash) with FIBER_USE_NATIVE=1 and it worked on the first try, the crashed on the next one. Not sure they are the same bug, but probably related.

[aselder (Andrew Selder)]

I'm also running into this same SegFault while running a Rails app (https://bugs.ruby-lang.org/issues/15308).

Same symptoms, Mac OS X, and segfault in rb_execution_context_mark()

[renchap (Renaud Chaput)]

I just ran my test suite 5 times with Ruby 2.6.0 on macOS 10.14.2 and have not been able to reproduce this crash anymore.

Could you please all check if you still see this crash with the latest release?

[aselder (Andrew Selder)]

I believe this was fixed here: https://bugs.ruby-lang.org/issues/15362

[wanabe (_ wanabe)]

• Related to Bug #14561: Consistent 2.5.0 seg fault in GC, related to accessing an enumerator in a thread added

[wanabe (_ wanabe)]

• Related to Bug #15362: [PATCH] Avoid GCing dead stack after switching away from a fiber added

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed