From: "hsbt (Hiroshi SHIBATA) via ruby-core" Date: 2026-11-05T00:31:40+00:00 Subject: [ruby-core:127339] [Ruby Bug#22509] MMTk: GC.start panics with "failed to re-disable GC after GC" while a Ractor is being created Issue #22509 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22509: MMTk: GC.start panics with "failed to re-disable GC after GC" while a Ractor is being created https://bugs.ruby-lang.org/issues/22509 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-11-03T16:41:26Z master a8b095a07e) +PRISM +GC[mmtk] [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The mmtk jobs of the ModGC workflow fail intermittently at `bootstraptest/test_ractor_nt_switch.rb:190`, where 8 Ractors call `GC.start` repeatedly. Over the 7 days from 2026-10-29 to 11-04, 21 of 376 ModGC run attempts (5.6%) failed this way, about a third of the attempts where an mmtk job failed. On master it was 5 of 120 pushes (4.2%). The ubuntu job hits it more often, 18 of 362 jobs (5.0%) against 3 of 335 on macOS (0.9%). ``` thread '' (62192) panicked at src/api.rs:311:33: failed to re-disable GC after GC 2: mmtk_handle_user_collection_request 3: gc_start_internal at ../src/gc.c:4370:5 :66: [BUG] Ruby mutator thread panicked ``` MMTk has one process-wide switch for collection, and `rb_gc_impl_gc_disable` in `gc/mmtk/mmtk.c` flips it whatever objspace it is given. Since per-Ractor GC (Feature #22227), `Ractor.new` disables GC for the child's objspace while it allocates the child's main thread, so with MMTk that turns off collection for every Ractor. When GC is disabled, `mmtk_handle_user_collection_request` enables collection, collects, and disables it again. If another Ractor has requested a GC in between, mmtk-core's `disable_collection` returns `Err` and the binding panics, as the TODO above it already notes. In 20 of the 21 crashes the bug report lists 4 to 8 Ractors, so the parent was still creating children. >From reading the code, if the parent re-enables GC before that re-disable, collection instead stays off with nothing left to enable it. I have not confirmed this. Failing jobs on master: https://github.com/ruby/ruby/actions/runs/41676768677/job/126059382824 https://github.com/ruby/ruby/actions/runs/41615058020/job/125846322767 https://github.com/ruby/ruby/actions/runs/41522777008/job/125542736708 https://github.com/ruby/ruby/actions/runs/41042731751/job/124019235630 https://github.com/ruby/ruby/actions/runs/40952873030/job/123725292165 Code: https://github.com/ruby/ruby/blob/65b5afc46740bc7a3cb0e085f68a371024d1ca3e/gc/mmtk/src/api.rs#L290-L313 https://github.com/ruby/ruby/blob/65b5afc46740bc7a3cb0e085f68a371024d1ca3e/gc/mmtk/mmtk.c#L827-L837 https://github.com/ruby/ruby/blob/65b5afc46740bc7a3cb0e085f68a371024d1ca3e/thread.c#L1159-L1169 https://github.com/mmtk/mmtk-core/blob/42c1ac176c4d931c5503e880e650bb9e84bf802c/src/mmtk.rs#L396-L407 -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/