- ruby-core - ml.ruby-lang.org

[ruby-core:126553] [Ruby Bug#22284] Passing an object with to_int to curry as its arity causes problems with LLP64.
by YO4 (Yoshinao Muramatsu) 02 Sep '26

02 Sep '26

Issue #22284 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22284: Passing an object with to_int to curry as its arity causes problems with LLP64. https://bugs.ruby-lang.org/issues/22284 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: master * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The proc_curry function in proc.c is affected by differences in behavior caused by the int size in FIX2INT. As a result, depending on the arguments, curry may not function correctly on Windows. ``` method(:puts).curry(1r).call(42) => #<Proc:0x0000000005e06c58 (lambda)> (Windows) => 42 (others) ``` The same thing happens in gems/src/rbs/test/stdlib/Proc_test.rb:113. It also triggers an assertion in a debug build on windows. ``` irb(main):001> method(:puts).curry(1r).call(42) S:\git\ruby\ruby\include\ruby/internal/arithmetic/long.h:192: Assertion Failed: rbimpl_fix2long_by_shift:RB_FIXNUM_P(x) ...(snip) -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF82F2E0404] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF82C53C11F] S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_print_backtrace+0x3e) [0x00007FFF45D706CA] S:\git\ruby\ruby\vm_dump.c:1137 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_vm_bugreport+0x288) [0x00007FFF45D70958] S:\git\ruby\ruby\vm_dump.c:1482 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure_detail+0xbb) [0x00007FFF45C05557] S:\git\ruby\ruby\error.c:1227 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(rb_assert_failure+0x12) [0x00007FFF45C0549A] S:\git\ruby\ruby\error.c:1202 S:\git\ruby\mswin64\x64-vcruntime140-ruby410.dll(proc_curry+0xfa) [0x00007FFF45D48426] S:\git\ruby\ruby\proc.c:4614 ...(snip) ``` proc.c:4614 has this ``` sarity = FIX2INT(arity); ``` FIX2INT is being used, and based on what I've read in doc/extension.rdoc, I'm not entirely sure if it's correct for curry to use to_int. So just reporting this for now before submitting a PR. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126555] [Ruby Bug#22286] Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing
by docelic (Davor Ocelic) 02 Sep '26

02 Sep '26

Issue #22286 has been reported by docelic (Davor Ocelic). ---------------------------------------- Bug #22286: Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing https://bugs.ruby-lang.org/issues/22286 * Author: docelic (Davor Ocelic) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Closing a TCPServer while another thread is blocked in accept can discard a just-accepted connection's file descriptor, leaving the peer connected to nothing. The script to reproduce the issue in each iteration binds a listener, starts a thread blocked in accept, connects a client, then tears the listener down in one of three orders. It then closes whatever the accept thread actually received and checks whether the client sees the peer go away within half a second. After a GC it reports how many descriptors the process still holds beyond its starting count. Results on Ruby 4.0.6, Linux 6.18. ``` ┌─────────────────────┬─────────────────────┬─────────────────────┐ │ mode │ stuck clients / 300 │ leaked fds after GC │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ close │ 89 │ 89 │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ shutdown │ 127 │ 127 │ ├─────────────────────┼─────────────────────┼─────────────────────┤ │ shutdown-join-close │ 0 │ 0 │ └─────────────────────┴─────────────────────┴─────────────────────┘ ``` Every stuck client is one the accept thread never handed back, and the leaked descriptor count matches. So accept(2) returned a socket, but Ruby raised the "closed in another thread" interrupt in that thread before wrapping the descriptor, and the descriptor was dropped. Joining the accept thread before calling close avoids the issue. Run the script with: ``` # The number of issue occurrences will be reported in hang/not-accepted/fd-delta value. ruby accept_race.rb close # issue visible ruby accept_race.rb shutdown # confirms issue coming from close-interrupt ruby accept_race.rb shutdown-join-close # workaround to fix the issue ``` ---Files-------------------------------- tcpserver-close-bug.rb (759 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126554] [Action Required] :️ Suspicious Activities Detected on ruby-core@ruby-lang.org
by Postmaster 01 Sep '26

01 Sep '26

1 0

[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