Issue #22228 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #22228: Do a major GC in YJIT test helper `assert_compiles` before running the test code https://bugs.ruby-lang.org/issues/22228 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-04T15:30:26Z master 036159508e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I was debugging why a YJIT test added from backport to 3.3.11 with GC.stress fails downstream. This revealed an assumption in the assert_compiles, that the environment is "clean", or as default as possible. `assert_compiles` already sanitizes environment with `--disable-gems` and `reset_stats!` call. I'd like to propose the `assert_compiles` method to trigger a GC.start before executing the test proc, and before the stats reset. While the issue described below does not happen on default Rubies 3.4 and 4.0, it could enhance the YJIT test environment. I was investigating downstream test failure on Ruby 3.3.11 (and later 3.3.12) [0] that appeared after backport of: https://bugs.ruby-lang.org/issues/21266 Where the tests in YJIT expects no exits by default: Provided as a default here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2015 Expected as part of condition here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2080 Downstream we insert hook for optional ABRT error reporting for Ruby: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad51... Relevant patchfile: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad51... We create empty `abrt.rb` to test with later on: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad51... To reproduce the failure in 3.3, both the patch and the file are required to exist for the failure at [0] to appear. Later I found that parse.y opens a file to load the abrt.rb and registers it with Ruby GC, which causes zombie and interrupt on `GC.stress=true`, since prism parser became default, these failures no longer appear as the parser does not copy parse.y's approach of registering the opened file with Ruby GC. The note on #19921 https://bugs.ruby-lang.org/issues/19921#note-20 regarding this was correct and it's also the earliest known appearance of the issue. --- [0] Test failure result: TestYJIT#test_proc_block_with_kwrest = 0.08 s 1) Failure: TestYJIT#test_proc_block_with_kwrest [/builddir/build/BUILD/ruby-3.3.11/test/ruby/test_yjit.rb:1531]: Expected no exits, but got: {:send=>1} Reasons: method call fallback reasons: iseq_has_kwrest: 1 (100.0%) invokeblock fallback reasons: proc: 2 (100.0%) invokesuper fallback reasons: (all relevant counters are zero) method call exit reasons: interrupted: 1 (100.0%) invokeblock exit reasons: (all relevant counters are zero) invokesuper exit reasons: (all relevant counters are zero) getblockparamproxy exit reasons: (all relevant counters are zero) getinstancevariable exit reasons: (all relevant counters are zero) setinstancevariable exit reasons: (all relevant counters are zero) leave exit reasons: interp_return: 6 (100.0%) left shift (ltlt) exit reasons: (all relevant counters are zero) invalidation reasons: constant_ic_fill: 2 (100.0%) -- https://bugs.ruby-lang.org/