Issue #19773 has been updated by eightbitraptor (Matthew Valentine-House). It looks like 3 of us have independently fixed this issue (in [#8084](https://github.com/ruby/ruby/pull/8084), [#8085](https://github.com/ruby/ruby/pull/8085), and [#8089](https://github.com/ruby/ruby/pull/8089)). Nobu's fix in 8085 has already been merged so I'm closing this ticket. ---------------------------------------- Bug #19773: Intermittent SIGSEGV during marking of Ripper parser https://bugs.ruby-lang.org/issues/19773#change-103913 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Github PR 8089](https://github.com/ruby/ruby/pull/8089) Intermittent SIGSEGV during marking of the Ripper parser. A failing build [can be seen on ci.rvm.jp (build 4643684)](http://ci.rvm.jp/results/trunk-random2@ruby-sp2-docker/4643684). Inside `ripper_s_allocate` first we use `TypedData_Make_Struct` to create a new `T_DATA` object in the Ruby heap. This allocates an empty struct (`struct ripper`). Further down the function we allocate another struct (`struct parser_params` during `rb_ruby_ripper_parser_allcoate`) and assign it to a pointer from the first struct, which is attached to the `T_DATA` object. `rb_ruby_ripper_parser_allocate` can trigger GC, as it uses `ruby_xcalloc`. But if GC is triggered at this point then the `parser_params` have not been allocated yet, and so the `struct ripper` contains a `NULL` reference. This causes a SEGV when we try and mark the `T_DATA` wrapper around the `struct ripper`. This can be replicated locally using the following test script ``` require "ripper" GC.stress = true Ripper.new ``` -- https://bugs.ruby-lang.org/