August 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:126513] [Ruby Bug#22269] `Coverage.line_stub` clobbers already-collected coverage data
by mugikurash (Shuta Mugikura) 06 Sep '26

06 Sep '26

Issue #22269 has been reported by mugikurash (Shuta Mugikura). ---------------------------------------- Bug #22269: `Coverage.line_stub` clobbers already-collected coverage data https://bugs.ruby-lang.org/issues/22269 * Author: mugikurash (Shuta Mugikura) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-27T01:47:31Z master 5ee95de080) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Coverage.line_stub` compiles the file with `compile_file` only to read the ISeq's `trace_points`. Since https://bugs.ruby-lang.org/issues/22018 `compile_file` registers the file into the coverage table, so calling `line_stub` while `Coverage` is running resets the file's already-collected counters. This also reproduces on 3.4 and 4.0, so I would like it backported. Reproduction: ```ruby require "coverage" f = File.expand_path("m.rb") File.write(f, "def m\n :ok\nend\n") Coverage.start require f m p Coverage.peek_result[f] Coverage.line_stub(f) p Coverage.peek_result[f] m p Coverage.result[f] ``` Expected: ``` [1, 1, nil] [1, 1, nil] [1, 2, nil] ``` Actual: ``` [1, 1, nil] [0, 0, nil] [0, 0, nil] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120897] [Ruby master Bug#21119] Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly.
by genya0407 (Yusuke Sangenya) 05 Sep '26

05 Sep '26

Issue #21119 has been reported by genya0407 (Yusuke Sangenya). ---------------------------------------- Bug #21119: Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly. https://bugs.ruby-lang.org/issues/21119 * Author: genya0407 (Yusuke Sangenya) * Status: Open * ruby -v: ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Executing the following code in Ruby 3.4.1 takes a very long time, especially when there are many files $100~$ in the current directory. This delay does not occur in Ruby 3.3.6. ## Reproducible script ```ruby # hoge.rb # Launch a thread to execute CPU-heavy task Thread.new do loop do arr = [] 100.times do arr << rand(1...100) end end end # Execute a program containing `Dir.glob` in the main thread. 10.times do Dir.glob('*') puts "aaaa" end ``` ## Execution Results Executiong the above code in Ruby 3.4.1 takes **119.43s**. ```shell $ ruby -v ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 119.43s user 0.30s system 99% cpu 1:59.89 total ``` Executing it in Ruby master also takes **118.87s**. ```shell $ ~/opt-ruby/bin/ruby -v ruby 3.5.0dev (2025-02-06T14:10:34Z master adbf9c5b36) +PRISM [arm64-darwin24] $ time ~/opt-ruby/bin/ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ~/opt-ruby/bin/ruby hoge.rb 118.87s user 0.46s system 99% cpu 2:00.45 total ``` Executing it in Ruby 3.3.6 takes only **2.22s**. ```shell $ ruby -v ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [arm64-darwin24] $ time ruby hoge.rb aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ruby hoge.rb 2.22s user 0.03s system 98% cpu 2.286 total ``` So, there are roughly **50x** delays. ## Possible Cause From Ruby 3.4.0, `Dir.glob` releases the GVL frequently. * https://bugs.ruby-lang.org/issues/20587 * https://github.com/ruby/ruby/pull/11147 Due to this change, when a CPU-heavy thread releases the GVL, `Dir.glob` also releases the GVL immediately. As a result, `Dir.glob` gets significantly delayed because it has to continuously regain the GVL causing a major slowdown in execution. ## Note about Execution Results I measured the execution results under a stress condition, with 100 files in the current directory. If there are fewer files, the slowdown may be less pronounced. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:126549] [Ruby Feature#22281] Feature: Permit `#with_index` to be used with `#times` in a "simpler" format
by LukeH7789 (Luke Hill) 31 Aug '26

31 Aug '26

Issue #22281 has been reported by LukeH7789 (Luke Hill). ---------------------------------------- Feature #22281: Feature: Permit `#with_index` to be used with `#times` in a "simpler" format https://bugs.ruby-lang.org/issues/22281 * Author: LukeH7789 (Luke Hill) * Status: Open ---------------------------------------- ## Synopsis This is half a bug. Half a feature request (And my first), so bare with me. When using `Array#each_with_index` or `Array#each` then chaining `#with_index`, it works as expected. However when using `Integer#times` then chaining `#with_index` it ignores the supplied argument. I investigated this further and found that it's working "semi" as expected, but in a non-standard way when using times. Where we only have a single value being iterated. As such storing a secondary "new" index, alongside the previous "old" index, feels a bit redundant, possibly a waste of resources, and I would argue **never** valuable. Why would you ask for a new index, but yet rely on the old one?? ## Examples ``` 4.0.5 :001 > 3.times do |i| 4.0.5 :002 > p i 4.0.5 :003 > end 0 1 2 4.0.5 :004 > 3.times.with_index(5) do |i| 4.0.5 :005 > p i 4.0.5 :006 > end 0 1 2 4.0.5 :007 > 3.times.to_a => [0, 1, 2] 4.0.5 :008 > 3.times.with_index(5).to_a => [[0, 5], [1, 6], [2, 7]] ``` The last example suggests that each of the `#with_index` calls is not mutating the index, but adding a second index value on. I investigated this further ``` 4.0.5 :009 > %i(a b c) => [:a, :b, :c] 4.0.5 :010 > %i(a b c).each_with_index.to_a => [[:a, 0], [:b, 1], [:c, 2]] 4.0.5 :011 > %i(a b c).each.with_index.to_a => [[:a, 0], [:b, 1], [:c, 2]] 4.0.5 :012 > %i(a b c).each.with_index(5).to_a => [[:a, 5], [:b, 6], [:c, 7]] 4.0.5 :013 > 3.times.with_index(5) do |_unused_i, i| 4.0.5 :014 > p i 4.0.5 :015 > end 5 6 7 ``` ## Suggestion/Request/Solution I therefore propose that when calling `Integer#times` and then chaining `#with_index` we mutate the iterating index in question (Same as we do when using `Array#times` and then chaining `#with_index` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124461] [Ruby Bug#21830] Ruby::Box and Kernel#require
by fxn (Xavier Noria) 30 Aug '26

30 Aug '26

Issue #21830 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21830: Ruby::Box and Kernel#require https://bugs.ruby-lang.org/issues/21830 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- If you enable `Ruby::Box`, decorations to `Kernel#require` do not work. For example, given `foo.rb`: ```ruby # foo.rb % cat foo.rb module M def require(_path) puts "decorated" super end end Kernel.prepend(M) require 'tsort' ``` the decoration works normally: ``` % ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] decorated ``` and the same code does not work with the feature enabled: ``` % RUBY_BOX=1 ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. ``` With this, Zeitwerk cannot work because it totally depends on `Kernel#require` decoration (done [here](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core_ext/kerne…) Bootsnap also depends on the ability of decorating `Kernel#require` (done [here](https://github.com/rails/bootsnap/blob/main/lib/bootsnap/load_path_ca…) On one hand, these gems are walking a fine line in the border of the public interface of Ruby. On the other hand, it is a goal of boxes to be transparent to the code being loaded under them. @tagomoris what should be the way to go in your opinion? /cc @byroot -- https://bugs.ruby-lang.org/

3 6

[ruby-core:116615] [Ruby master Bug#20243] M:N threading VM_ASSERT failure in rb_current_execution_context with clang 17 (on Linux)
by kjtsanaktsidis (KJ Tsanaktsidis) 30 Aug '26

30 Aug '26

Issue #20243 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20243: M:N threading VM_ASSERT failure in rb_current_execution_context with clang 17 (on Linux) https://bugs.ruby-lang.org/issues/20243 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When building with Clang 17 and `-DVM_CHECK_MODE=1` (with the following configure) ``` optflags="-ggdb3 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O3" cflags="-DVM_CHECK_MODE=1" CC=clang ../configure --prefix=/home/kj/ruby/installed --enable-yjit=dev --disable-install-doc ``` And then running the following script with the built `./miniruby` (which is actually from `bootstraptest/test_ractor.rb`): ```ruby counts = [] counts << Ractor.count ractors = (1..3).map { Ractor.new { Ractor.receive } } counts << Ractor.count ractors[0].send('End 0').take sleep 0.1 until ractors[0].inspect =~ /terminated/ counts << Ractor.count ractors[1].send('End 1').take sleep 0.1 until ractors[1].inspect =~ /terminated/ counts << Ractor.count ractors[2].send('End 2').take sleep 0.1 until ractors[2].inspect =~ /terminated/ counts << Ractor.count counts.inspect ``` I get the following crash: ``` Assertion Failed: ../vm_core.h:1957:rb_current_execution_context:ec == rb_current_ec_noinline() ruby 3.4.0dev (2024-02-07T07:52:06Z ktsanaktsidis/igno.. 5cc6d944c2) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0003 s:0010 e:000009 METHOD <internal:ractor>:431 c:0002 p:0004 s:0006 e:000005 BLOCK ractor_crash.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ractor_crash.rb:3:in `block (2 levels) in <main>' <internal:ractor>:431:in `receive' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/kj/ruby/build/miniruby(rb_print_backtrace+0x14) [0x55faa97a4ebd] ../vm_dump.c:820 /home/kj/ruby/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1151 /home/kj/ruby/build/miniruby(rb_assert_failure+0x81) [0x55faa94d2719] ../error.c:1131 ./miniruby(thread_sched_wait_running_turn+0x2e9) [0x55faa9726f59] /home/kj/ruby/build/miniruby(rb_ractor_sched_sleep+0x10b) [0x55faa972687b] ../thread_pthread.c:1348 /home/kj/ruby/build/miniruby(ractor_check_ints+0x0) [0x55faa968b328] ../ractor.c:683 /home/kj/ruby/build/miniruby(ractor_sleep_with_cleanup) ../ractor.c:684 /home/kj/ruby/build/miniruby(ractor_sleep+0x15) [0x55faa968adf4] ../ractor.c:701 /home/kj/ruby/build/miniruby(ractor_wait_receive) ../ractor.c:748 /home/kj/ruby/build/miniruby(ractor_receive+0x1f) [0x55faa968768e] ../ractor.c:762 /home/kj/ruby/build/miniruby(builtin_inline_class_431) ../ractor.rb:432 /home/kj/ruby/build/miniruby(builtin_invoker0+0x6) [0x55faa978fc66] ../vm_insnhelper.c:6746 /home/kj/ruby/build/miniruby(invoke_bf+0x39) [0x55faa979816e] ../vm_insnhelper.c:6886 /home/kj/ruby/build/miniruby(vm_invoke_builtin_delegate) ../vm_insnhelper.c:6909 /home/kj/ruby/build/miniruby(rb_vm_check_ints+0x0) [0x55faa9771fac] ../insns.def:1533 /home/kj/ruby/build/miniruby(vm_pop_frame) ../vm_insnhelper.c:419 /home/kj/ruby/build/miniruby(vm_exec_core) ../insns.def:1537 /home/kj/ruby/build/miniruby(vm_exec_loop+0x0) [0x55faa9767f02] ../vm.c:2489 /home/kj/ruby/build/miniruby(rb_vm_exec) ../vm.c:2492 /home/kj/ruby/build/miniruby(invoke_block+0x6f) [0x55faa9781a58] ../vm.c:1512 /home/kj/ruby/build/miniruby(invoke_iseq_block_from_c) ../vm.c:1582 /home/kj/ruby/build/miniruby(invoke_block_from_c_proc) ../vm.c:1680 /home/kj/ruby/build/miniruby(vm_invoke_proc) ../vm.c:1710 /home/kj/ruby/build/miniruby(rb_vm_invoke_proc_with_self+0x5a) [0x55faa9781eaa] ../vm.c:1745 /home/kj/ruby/build/miniruby(thread_do_start_proc+0x199) [0x55faa9739e19] ../thread.c:574 /home/kj/ruby/build/miniruby(thread_do_start+0x6c) [0x55faa973933f] ../thread.c:618 /home/kj/ruby/build/miniruby(thread_start_func_2) ../thread.c:668 /home/kj/ruby/build/miniruby(rb_native_mutex_lock+0x0) [0x55faa973a141] ../thread_pthread.c:2234 /home/kj/ruby/build/miniruby(thread_sched_lock_) ../thread_pthread.c:387 /home/kj/ruby/build/miniruby(call_thread_start_func_2) ../thread_pthread_mn.c:436 /home/kj/ruby/build/miniruby(co_start) ../thread_pthread_mn.c:434 ``` The failing assertion is this one in vm_core.h: https://github.com/ruby/ruby/blob/42c36269403baac67b0d5dc1d6d6e31168cf6a1f/…. It actually has a very helpful comment. ``` /* On the shared objects, `__tls_get_addr()` is used to access the TLS * and the address of the `ruby_current_ec` can be stored on a function * frame. However, this address can be mis-used after native thread * migration of a coroutine. * 1) Get `ptr =&ruby_current_ec` op NT1 and store it on the frame. * 2) Context switch and resume it on the NT2. * 3) `ptr` is used on NT2 but it accesses to the TLS on NT1. * This assertion checks such misusage. * * To avoid accidents, `GET_EC()` should be called once on the frame. * Note that inlining can produce the problem. */ VM_ASSERT(ec == rb_current_ec_noinline()); ``` What seems to be happening is exactly that. This is a disassembly of the relevant bits of `thread_sched_wait_running_turn`: ``` ........ # This is the only bits of the entire function which access the TLS base register %fs. # It seems to have spilled the value of ruby_current_ec into %r13. 0x000055603d2e1cf8 <+136>: mov $0xffffffffffffff90,%rax 0x000055603d2e1cff <+143>: mov %fs:0x0,%r12 0x000055603d2e1d08 <+152>: add %rax,%r12 0x000055603d2e1d0b <+155>: mov %fs:(%rax),%r13 ........ # There's a call to coroutine_transfer, so after this point we're returned to on a # different thread 0x000055603d2e1e90 <+544>: call 0x55603d7fce84 <coroutine_transfer> # But nothing ever loads the address of ruby_current_ec from %fs again (i didn't trace # exactly the data flow from %r13 at 0x000055603d2e1d0b to here, but i assume it spilled # somewhere and now got loaded back into %r15 here). In any case, that means %r15 here # contains the value of ruby_current_ec from the _old_ thread, not the current one. 0x000055603d2e1e95 <+549>: mov %rbx,0x28(%r14) 0x000055603d2e1e99 <+553>: mov (%r12),%r15 0x000055603d2e1e9d <+557>: call 0x55603d33a010 <rb_current_ec_noinline> 0x000055603d2e1ea2 <+562>: cmp %rax,%r15 => 0x000055603d2e1ea5 <+565>: jne 0x55603d2e1f3a <thread_sched_wait_running_turn+714> ........ # assertion failure code path. 0x000055603d2e1f3a <+714>: lea 0x542c0c(%rip),%rdi # 0x55603d824b4d 0x000055603d2e1f41 <+721>: lea 0x542c12(%rip),%rdx # 0x55603d824b5a 0x000055603d2e1f48 <+728>: lea 0x542c28(%rip),%rcx # 0x55603d824b77 0x000055603d2e1f4f <+735>: mov $0x7a5,%esi 0x000055603d2e1f54 <+740>: call 0x55603d08d698 <rb_assert_failure> ``` if we look at the register values from `0x000055603d2e1ea2`: ``` (rr) print/x $rax $2 = 0x55603e159ad0 (rr) print/x $r15 $3 = 0x0 ``` So the value from `%rax` which came from `ruby_current_ec_noinline` is correctly the value of `ruby_current_ec` for this thread, and `%r15` contains a stale value from a previous thread. - Now, what can we _do_ about this, is a different question :/ There's a really good stackoverflow answer about it here: https://stackoverflow.com/questions/75592038/how-to-disable-clang-expressio…, but to summarise * longstanding GCC and Clang bugs for this exist and have been marked as WONTFIX (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461, https://github.com/llvm/llvm-project/issues/19551) * It's even worse than this EC problem - things like `errno` also might be incorrectly persisted across coroutine switches (so e.g. an inlined C library function could in theory set `errno` in another thread, for example) * C++ actually has coroutines now, so this _must_ work for those. Clang at least has fixed some TLS problems in their C++ coroutine implementation (https://github.com/llvm/llvm-project/issues/47179) Other than reimplementing all of our coroutine stuff on top of C++ coroutines, I'm not sure what else we can do. AFAICT there's no way to tell the compiler that we clobbered the `%fs` register because that's just not a thing in its model (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631, but i assume clang is similar). Thoughts? For now I think my workaround is to disable M:N at build time when building with ASAN (or turn optimizations down). At least this isn't a problem with `Fiber` because we never move them across threads (probably for this reason in part). -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120034] [Ruby master Bug#20917] redo/next in nested begin block causes wrong order of execution
by hoshiumiarata (Arata Hoshiumi) 30 Aug '26

30 Aug '26

Issue #20917 has been reported by hoshiumiarata (Arata Hoshiumi). ---------------------------------------- Bug #20917: redo/next in nested begin block causes wrong order of execution https://bugs.ruby-lang.org/issues/20917 * Author: hoshiumiarata (Arata Hoshiumi) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that `redo`/`next` in a nested `begin` block can cause the wrong order of execution. For example: ```ruby for _ in [0] puts 0 begin puts 1 begin puts 2 redo ensure puts 3 end ensure puts 4 break end end ``` It prints: ``` 0 1 2 3 4 3 4 => nil ``` But I think it should print: ``` 0 1 2 3 4 => nil ``` Because execution order should be: 1. `puts 0` 2. `puts 1` 3. `puts 2` 4. `redo` 5. unwind to nested `ensure` block 6. `puts 3` 7. unwind to outer `ensure` block 8. `puts 4` 9. `break` 10. end of loop Interestingly enough, if we add an empty `rescue` block before any of the `ensure` blocks, then the execution order is correct. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126545] [Ruby Bug#22268] Backport resolv security fixes (CVE-2026-80212, CVE-2026-80213)
by nagachika (Tomoyuki Chikanaga) 30 Aug '26

30 Aug '26

Issue #22268 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED Thank you for creating PR. merged into ruby_3_4 at commit:6deacfb8275bd1583ffa1b8c2b87f25484586a91. ---------------------------------------- Bug #22268: Backport resolv security fixes (CVE-2026-80212, CVE-2026-80213) https://bugs.ruby-lang.org/issues/22268#change-118731 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED ---------------------------------------- The resolv security releases of 2026-08-27 fix CVE-2026-80212 and CVE-2026-80213. https://www.ruby-lang.org/en/news/2026/08/27/multiple-vulnerabilities-in-re… `resolv` is a default gem. master already has the fixes through the automatic sync from `ruby/resolv`, but the stable branches do not. | Branch | Current | Target | PR | | --- | --- | --- | --- | | `ruby_4_0` | 0.7.0 | 0.7.2 | https://github.com/ruby/ruby/pull/18528 | | `ruby_3_4` | 0.7.1 | 0.7.2 | https://github.com/ruby/ruby/pull/18529 | | `ruby_3_3` | 0.3.1 | 0.3.2 | https://github.com/ruby/ruby/pull/18530 | -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126395] [Ruby Bug#22246] Rational#to.f incorrectly rounds when the numerator is a bignum that cannot be represented exactly by a double, and the denominator is a fixnum
by AndrewDile (Andrew Dile) 28 Aug '26

28 Aug '26

Issue #22246 has been reported by AndrewDile (Andrew Dile). ---------------------------------------- Bug #22246: Rational#to.f incorrectly rounds when the numerator is a bignum that cannot be represented exactly by a double, and the denominator is a fixnum https://bugs.ruby-lang.org/issues/22246 * Author: AndrewDile (Andrew Dile) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` c Rational(65803600513127829623, 10**12).to_f ``` The bignum numerator cannot be exactly represented by a double, but the code in `rb_big_fdiv_double` rounds it to a double (`dx`) before dividing by the fixnum denominator of 10^12, resulting in `65803600.51312783`, instead of the correctly rounded value, `65803600.513127826`. The `isinf(dx)` test does not cover this case. Moreover, not all fixnums (in 64-bit systems) can be represented exactly as doubles. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:126497] [Ruby Bug#22263] Subject: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to 98f0921f2b)
by yahonda (Yasuo Honda) 28 Aug '26

28 Aug '26

Issue #22263 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22263: Subject: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to 98f0921f2b) https://bugs.ruby-lang.org/issues/22263 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-25T14:03:04Z master 17026737cc) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### 1. First occurrence in Rails CI https://buildkite.com/rails/rails-nightly/builds/4651#01a016ac-eaf9-4a71-9f… (job "activemodel (master-debug)", 2026-08-18, ruby 4.1.0dev (2026-08-18T13:12:35Z master 6b719acc57) +PRISM [x86_64-linux]) Two Active Model tests ran a short-lived Ractor in the test process. A few seconds later, `RailtieTest` forked child processes (Active Support's fork-based test isolation), and the children failed while booting a Rails application. ### 2. Steps to reproduce A Rails checkout is required. Verified with Rails main 0f36bbf72c and the `rubylang/ruby:master` Docker image (ruby 4.1.0dev (2026-08-25T07:50:12Z master 753ace46fe)); it reproduces every run. ``` $ git clone https://github.com/rails/rails && cd rails && bundle install $ cd activemodel $ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb ``` ### 3. Expected behavior The forked child behaves like its parent: the Rails application boots and the child exits with status 0 (`child: #<Process::Status: pid NNN exit 0>`). The test pair reports 0 errors. ### 4. Actual behavior The forked child raises an exception during `require` and exits with status 1; the parent process is unaffected: ``` $ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb Source locally installed gems is ignoring #<Bundler::StubSpecification name=psych version=5.5.0 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=prism version=1.9.0 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.8.2 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.9.2 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=erb version=6.0.7 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=date version=3.5.1 platform=ruby> because it is missing extensions Run options: --seed 20598 # Running: ............................................................E Error: RailtieTest#test_i18n_customize_full_message_defaults_to_false: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:36 E Error: RailtieTest#test_secure_password_min_cost_is_false_in_the_development_environment: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:22 E Error: RailtieTest#test_i18n_customize_full_message_can_be_disabled: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:42 E Error: RailtieTest#test_secure_password_min_cost_is_true_in_the_test_environment: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:29 E Error: RailtieTest#test_i18n_customize_full_message_can_be_enabled: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:49 Finished in 0.088916s, 731.0243 runs/s, 820.9965 assertions/s. 65 runs, 73 assertions, 0 failures, 5 errors, 0 skips $ ``` ### 5. Bisect result ``` 98f0921f2b06bcc6435fe96a99da3a857ac10477 introduces this behavior. ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:125377] [Ruby Bug#22018] ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage
by byroot (Jean Boussier) 28 Aug '26

28 Aug '26

Issue #22018 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22018: ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage https://bugs.ruby-lang.org/issues/22018 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction: ```ruby require "coverage" File.write("/tmp/a.rb", <<~RUBY) module CoverableRaw def self.call "cover up" end end CoverableRaw.call RUBY Coverage.start require "/tmp/a.rb" p Coverage.result File.write("/tmp/b.rb", <<~RUBY) module Coverable def self.call "cover up" end end Coverable.call RUBY class RubyVM::InstructionSequence def self.load_iseq(path) compile_file(path) end end Coverage.start require "/tmp/b.rb" p Coverage.result ``` Expected: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {"/tmp/b.rb" => [1, 1, 1, nil, nil, nil, 1]} ``` Actual: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {} ``` Patch: https://github.com/ruby/ruby/pull/16805 -- https://bugs.ruby-lang.org/

3 4