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

[ruby-core:126201] [Ruby Bug#22220] Performance regression when requiring `aws-sdk-ec2` in Ruby 4.0.6
by emanuelevans (Emanuel Evans) 14 Sep '26

14 Sep '26

Issue #22220 has been reported by emanuelevans (Emanuel Evans). ---------------------------------------- Bug #22220: Performance regression when requiring `aws-sdk-ec2` in Ruby 4.0.6 https://bugs.ruby-lang.org/issues/22220 * Author: emanuelevans (Emanuel Evans) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.6 introduced a large performance regression when loading `aws-sdk-ec2` (~30s on my machine, compared to <1s for ruby 4.0.5). Script to reproduce: ``` for v in 4.0.5 4.0.6; do docker run --rm ruby:$v-slim bash -c ' gem install --no-document aws-sdk-ec2 -v 1.402.0 >/dev/null 2>&1 ruby -e "t = Process.clock_gettime(Process::CLOCK_MONOTONIC) require \"aws-sdk-ec2\" printf(\"ruby %s: %.2fs\n\", RUBY_VERSION, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t)"' done ``` It appears to be related to `Shape.new` and/or `Class.new` compile times; minimal reproduction: ``` for v in 4.0.5 4.0.6; do docker run --rm ruby:$v-slim ruby -e ' src = "class Shape\n def self.new(**) = nil\nend\nmodule M\n" + (1..16_000).map { |i| %( K_#{i} = Shape.new(name: "k#{i}")) }.join("\n") + "\nend\n" File.write("/tmp/bench.rb", src) t = Process.clock_gettime(Process::CLOCK_MONOTONIC) RubyVM::InstructionSequence.compile_file("/tmp/bench.rb") printf("ruby %s: %.2fs\n", RUBY_VERSION, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t)' done ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126098] [Ruby Bug#22198] win32: heap overflow in Kernel#system
by mame (Yusuke Endoh) 14 Sep '26

14 Sep '26

Issue #22198 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22198: win32: heap overflow in Kernel#system https://bugs.ruby-lang.org/issues/22198 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: windows * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `system('foo.exe %A')` looks past `%A` for a closing `%`, reading past the end of the string. It does not reproduce normally, but with page heap enabled it faults: ``` PS C:\> gflags /p /enable ruby.exe /full PS C:\> ruby -e "system('x' * 1024 + '.exe %A')" -e:1: [BUG] Segmentation fault ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 l:y b:0001 CFUNC :system c:0002 p:0013 s:0006 e:000005 l:n b:---- EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001620 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'system' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007ffbd55000e4] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007ffbd274c11f] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_vm_bugreport+0x237) [0x00007ffb37262227] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_bug_for_fatal_signal+0x9b) [0x00007ffb37000beb] C:\Users\YusukeEndoh\scoop\apps\ruby\current\bin\x64-ucrt-ruby400.dll(rb_shape_free_all+0xfb5) [0x00007ffb37191985] C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007ffbd2fff2e4] [0x00007ff765e81080] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007ffbd550479f] *snip* ``` PR: https://github.com/ruby/ruby/pull/17929 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126038] [Ruby Bug#22190] Class#subclasses does not include clones of classes that include modules
by shugo (Shugo Maeda) 14 Sep '26

14 Sep '26

Issue #22190 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22190: Class#subclasses does not include clones of classes that include modules https://bugs.ruby-lang.org/issues/22190 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 4.0 * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Class#subclasses` does not return clones of classes that include (or prepend) a module, while clones of classes without modules are returned. This is a regression first released in Ruby 4.0.4. ```ruby module M; end class X; end class C < X include M end class D < X; end clone_c = C.clone clone_d = D.clone p clone_c.superclass #=> X p X.subclasses.include?(C) #=> true p X.subclasses.include?(clone_d) #=> true (D includes no module) p X.subclasses.include?(clone_c) #=> false (expected: true) ``` The same happens with `prepend` instead of `include`. Ruby 4.0.3 and earlier return `true` for all of the above. ## Analysis Since a2531ba293 ("Simplify subclasses list, remove from Box"), `class_associate_super()` maintains subclass lists only for direct T_CLASS -> T_CLASS links: ```c // class.c (master) // Only maintain subclass lists for T_CLASS→T_CLASS relationships. // Include/prepend inserts ICLASSes into the super chain, but T_CLASS // subclass lists should track only the immutable T_CLASS→T_CLASS link. if (RB_TYPE_P(klass, T_CLASS) && RB_TYPE_P(super, T_CLASS)) { ``` For normally created classes this is fine because the T_CLASS -> T_CLASS link is registered at class creation time, before any module is included. However, `rb_mod_init_copy()` builds the clone's superclass chain differently: * When the original has no origin, the clone shares the original's ICLASS chain: `rb_class_set_super(clone, RCLASS_SUPER(orig))` (class.c:983), where `RCLASS_SUPER(orig)` is a T_ICLASS. The condition above is false, so the clone is never added to the real superclass's subclass list. * When the original has an origin (prepend), the tail is connected via `rb_class_set_super(clone_origin, RCLASS_SUPER(orig_origin))` (class.c:1031), where `clone_origin` is a T_ICLASS, so this link is not registered either. Before a2531ba293, subclass entries were reparented onto ICLASSes and the `Class#subclasses` walk descended through non-T_CLASS entries (see `class_descendants_recursive` in 4.0.3), so a clone registered under the shared ICLASS was still found from the superclass. Method lookup and method cache invalidation do not seem to be affected (redefining a method on the superclass after cloning is observed correctly through the clone); the visible breakage is in the reflection API. Other users of the subclass lists may want checking, though (for example the allocator propagation added in 111215de27 also iterates subclass lists). -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 14 Sep '26

14 Sep '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125555] [Ruby Bug#22077] Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour
by jerome.paul＠gmail.com (Jerome Paul) 14 Sep '26

14 Sep '26

Issue #22077 has been reported by jerome.paul(a)gmail.com (Jerome Paul). ---------------------------------------- Bug #22077: Endless methods in 3.3.5 allows for endless rescues. 4.0 shows different behaviour https://bugs.ruby-lang.org/issues/22077 * Author: jerome.paul(a)gmail.com (Jerome Paul) * Status: Open * ruby -v: 3.4.x * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless => "please stop" irb(main):003> ``` ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [x86_64-linux] ``` irb(main):001> def endless = nil * 1000 rescue raise('surprise') rescue 'please stop' => :endless irb(main):002> endless (irb):1:in 'Object#endless': surprise (RuntimeError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/exe/irb:9:in '<top (required)>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Kernel#load' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/4.0.0/rubygems.rb:304:in 'Gem.activate_and_load_bin_path' from /home/jerome/.rbenv/versions/4.0.3/bin/irb:25:in '<main>' (irb):1:in 'Object#endless': undefined method '*' for nil (NoMethodError) from (irb):2:in '<main>' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'Kernel#eval' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/workspace.rb:110:in 'IRB::WorkSpace#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:591:in 'IRB::Context#evaluate_expression' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb/context.rb:557:in 'IRB::Context#evaluate' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:202:in 'block (2 levels) in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:521:in 'IRB::Irb#signal_status' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:194:in 'block in IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:281:in 'block in IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'Kernel#loop' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:278:in 'IRB::Irb#each_top_level_statement' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:193:in 'IRB::Irb#eval_input' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:174:in 'block in IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'Kernel#catch' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:173:in 'IRB::Irb#run' from /home/jerome/.rbenv/versions/4.0.3/lib/ruby/gems/4.0.0/gems/irb-1.16.0/lib/irb.rb:54:in 'IRB.start' ... 4 levels... ``` `ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux]` shows the same behaviour as 4.0.3. Being honest I don't think endless methods should allow for endless rescues! So the behaviour since at least 3.4.3 is IMO close to correct however instead of a runtime error I would expect a SyntaxError. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117750] [Ruby master Bug#20464] Redundant returns are unreachable in coverage
by kddnewton (Kevin Newton) 14 Sep '26

14 Sep '26

Issue #20464 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20464: Redundant returns are unreachable in coverage https://bugs.ruby-lang.org/issues/20464 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- With the following code: ```ruby def meth_return(a) return if a return end ``` If you run coverage on it, it's not possible for it to hit line 3, because there isn't a line event, because the return node was eliminated from the AST before it was compiled. There is a `putnil` instruction, so it's possible for us to attach a line event for it, but the compiler doesn't today. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 14 Sep '26

14 Sep '26

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 10

[ruby-core:123306] [Ruby Bug#21612] Make sure we never context switch while holding the VM lock
by luke-gru (Luke Gruber) 14 Sep '26

14 Sep '26

Issue #21612 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21612: Make sure we never context switch while holding the VM lock https://bugs.ruby-lang.org/issues/21612 * Author: luke-gru (Luke Gruber) * Status: Open * Target version: 3.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## The Problem We're seeing errors in our application that uses ractors. The errors look like: ``` [BUG] unexpected situation - recordd:1 current:0 error.c:1097 rb_bug_without_die_internal vm_sync.c:275 disallow_reentry eval_intern.h:136 rb_ec_vm_lock_rec_check eval_intern.h:147 rb_ec_tag_state vm.c:2619 rb_vm_exec vm.c:1702 rb_yield eval.c:1173 rb_ensure ``` We concluded that there was context switching going on while a thread held the VM lock. During the investigation into the issue, we added assertions in the code that we never yield to another thread with the VM lock held. We enabled these VM lock assertions even in single ractor mode. These assertions were failing in a few places, but most notably in finalizers. Finalizers are running with the VM lock held, and they were context switching and causing this issue. ## Why Is This Bad? There are a few reasons we shouldn't be able to context switch while holding the VM lock. In single-ractor mode with threads A and B: 1) Anything in this critical section should be thought of as a transaction related to the memory that's changed inside. if A has the lock, manipulates some global memory and yields to B with the lock still taken and without finishing the memory updates and then B takes it and starts writing to the same memory, the state of this global memory could be corrupted. Currently we don't actually take the VM lock in single-ractor mode, but that doesn't mean these issues can't happen. Yielding to another thread in the middle of manipulating global memory *can* still happen and it causes similar issues. In multi-ractor mode with ractors A and B: 1) We get the same issues as in single-ractor mode. 2) We can also get deadlocks if A has the lock, yields to B and B is blocked waiting on the lock. Unfortunately, many things can cause context switching in Ruby, so what is safe to call when the VM lock is taken? ## Guidelines I've come up with some guidelines. With the VM lock held, You should be able to: * Create ruby objects, call `ruby_xmalloc`, etc. * Jump using `EC_JUMP_TAG`. The lock will automatically be unlocked depending on how far up the call stack you locked it and where you're jumping to. * Check ruby interrupts. Since jumping can pop ruby frames and popping frames checks interrupts, you are allowed. It should never context switch with the VM lock held, even if the ruby thread's quantum is up. You shouldn't be able to: * Call any ruby method or enter Ruby's VM loop. For example, `rb_funcall` is not allowed, nor is `rb_warn` (it can call ruby code). `rb_sprintf` is not allowed because it can call `rb_inspect`. * Call `rb_nogvl` * Enter any blocking operation managed by Ruby. * Call a ruby-level mechanism that can context switch, like `rb_mutex_lock`. ## The Fix Of course, unlocking during finalizers is the main fix but there are other places that also need unlocking. I think adding assertions that the VM lock is not held will be important in finding these bugs and not creating regressions in the future. We don't have to add lots of these, just in a few places. These assertions, which only run in debug mode, should also run when in single-ractor mode. ## Future Work I think some documentation would be helpful for what is and isn't allowed while holding the VM lock and other locks in the cruby source. I am currently working on a `Concurrency Guide` for cruby developers that includes this info. It will not go over every lock, just the VM lock and the "all other locks" category. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116041] [Ruby master Bug#20155] Using value of rb_fiber_scheduler_current() crashes Ruby
by paddor (Patrik Wenger) 14 Sep '26

14 Sep '26

Issue #20155 has been reported by paddor (Patrik Wenger). ---------------------------------------- Bug #20155: Using value of rb_fiber_scheduler_current() crashes Ruby https://bugs.ruby-lang.org/issues/20155 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While trying to manually block/unblock fibers from an extension using the Fiber Scheduler, I noticed that using the return value of `rb_fiber_scheduler_current()` crashes Ruby. I've created a minimal extension gem called "fiber_blocker". Its test suite shows the behavior. See https://github.com/paddor/fiber_blocker, especially the lines containing `FIXME`. Passing `Fiber.scheduler` to the extension functions works. But letting it get the current scheduler itself does not seem to work. Is `rb_fiber_scheduler_current()` not the equivalent to `Fiber.scheduler`? Even just printing the its return value with `#p` will crash Ruby. Ruby either crashes like this: ``` # Running: T1 BEGIN T2 BEGIN T1 END ..T1 BEGIN ext: blocking fiber passed scheduler = #<Scheduler:0x00007fc5f22d39e8 @readable={}, @writable={}, @waiting={}, @closed=false, @lock=#<Thread::Mutex:0x00007fc5f22ec8d0>, @blocking={}, @ready=[], @urgent=[#<IO:fd 5>, #<IO:fd 6>]> T2 BEGIN ext: unblocking fiber T1 END .E Finished in 1.007014s, 3.9721 runs/s, 2.9791 assertions/s. 1) Error: TestFiberBlocker#test_fiber_blocker_current_fiber: fatal: machine stack overflow in critical region No backtrace ``` Or with a segfault: ``` # Running: FiberBlocker.test works. .T1 BEGIN T2 BEGIN T1 END .T1 BEGIN ext: blocking fiber /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40: [BUG] Segmentation fault at 0x00000000390d8f98 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 CFUNC :block_fiber c:0002 p:0014 s:0006 e:000005 BLOCK /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block in test_fiber_blocking_in_ext' /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block_fiber' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 4 -- Machine register context ------------------------------------------------ RIP: 0x00007f1554f17ad8 RBP: 0x00000000390d8f90 RSP: 0x00007f153a79e280 RAX: 0x00007f1554addba8 RBX: 0x00007f153a79eab0 RCX: 0x0000000000000000 RDX: 0x00007f1554ade600 RDI: 0x00007f15551e8788 RSI: 0x0000000000000ae1 R8: 0x000000000000002b R9: 0x00007f153a79f038 R10: 0x00007f1554c0b9b0 R11: 0x00007f153a79e490 R12: 0x0000000000000ae1 R13: 0x0000000000000000 R14: 0x0000000000000000 R15: 0x000055ab732d7df0 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_print_backtrace+0x14) [0x7f1554f24961] /home/user/src/ruby-3.3.0/vm_dump.c:820 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_bugreport) /home/user/src/ruby-3.3.0/vm_dump.c:1151 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0x104) [0x7f1554d1c214] /home/user/src/ruby-3.3.0/error.c:1065 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(sigsegv+0x4f) [0x7f1554e700df] /home/user/src/ruby-3.3.0/signal.c:926 /lib/x86_64-linux-gnu/libc.so.6(0x7f1554842520) [0x7f1554842520] /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_CLASS+0x0) [0x7f1554f17ad8] ./include/ruby/internal/globals.h:178 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(gccct_method_search) /home/user/src/ruby-3.3.0/vm_eval.c:475 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv_scope) /home/user/src/ruby-3.3.0/vm_eval.c:1063 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv) /home/user/src/ruby-3.3.0/vm_eval.c:1084 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_inspect+0x19) [0x7f1554dc1569] /home/user/src/ruby-3.3.0/object.c:697 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby__sfvextra+0x11a) [0x7f1554e7223a] /home/user/src/ruby-3.3.0/sprintf.c:1119 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(BSD_vfprintf+0xa69) [0x7f1554e73059] /home/user/src/ruby-3.3.0/vsnprintf.c:830 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_SET_CLASS_RAW+0x0) [0x7f1554e75b56] /home/user/src/ruby-3.3.0/sprintf.c:1168 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby_vsprintf0) /home/user/src/ruby-3.3.0/sprintf.c:1169 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_enc_vsprintf+0x5d) [0x7f1554e75ecd] /home/user/src/ruby-3.3.0/sprintf.c:1195 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_sprintf+0x9d) [0x7f1554e7607d] /home/user/src/ruby-3.3.0/sprintf.c:1225 /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/lib/fiber_blocker/fiber_blocker.so(block_fiber+0x4a) [0x7f1554ad430a] ../../../../ext/fiber_blocker/fiber_blocker.c:29 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_cfp_consistent_p+0x0) [0x7f1554ef64b4] /home/user/src/ruby-3.3.0/vm_insnhelper.c:3490 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame_) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3492 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3518 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_other) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3544 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_sendish+0x9e) [0x7f1554f06f87] /home/user/src/ruby-3.3.0/vm_insnhelper.c:5581 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_exec_core) /home/user/src/ruby-3.3.0/insns.def:834 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_exec+0x19a) [0x7f1554f0d1fa] /home/user/src/ruby-3.3.0/vm.c:2486 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_invoke_proc+0x5f) [0x7f1554f12e0f] /home/user/src/ruby-3.3.0/vm.c:1728 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_fiber_start+0x1ba) [0x7f1554cf098a] /home/user/src/ruby-3.3.0/cont.c:2536 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(fiber_entry+0x20) [0x7f1554cf0d00] /home/user/src/ruby-3.3.0/cont.c:847 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_threadptr_root_fiber_setup) (null):0 ``` I hope I'm not missing something obvious. My C isn't very good. -- https://bugs.ruby-lang.org/

2 12

[ruby-core:124711] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching
by synacker (Mikhail Milovidov) 12 Sep '26

12 Sep '26

Issue #21869 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21869: Add receive_all Method to Ractor API for Message Batching https://bugs.ruby-lang.org/issues/21869 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** The Ractor API provides an excellent mechanism for inter‑thread communication, but it currently lacks a built‑in message batching technique. I propose adding a receive_all method to enable batch processing of messages, which can significantly improve performance in high‑load scenarios. **Motivation** In distributed queued systems, processing messages one‑by‑one (as with the current receive method) can introduce unnecessary overhead. Batch processing allows: Reduced context‑switching overhead. More efficient I/O operations (e.g., fewer file writes). Better throughput in high‑concurrency environments. **Proposed Solution** Add a receive_all method to the Ractor API that: Returns all available messages in the Ractor’s mailbox at once (as an array). **Demonstration Code** Below is a benchmark comparing individual receive vs. batch receive_all: ``` ruby require 'benchmark' class RactorsTest def initialize(count) @count = count @ractor1 = Ractor.new(count, 'output1.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? message = receive file.write("Ractor 1 received message: #{message}\n") file.flush count -= 1 end end end @ractor2 = Ractor.new(count, 'output2.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? messages = receive_all messages.each do |message| file.write("Ractor 2 received message: #{message}\n") end count -= messages.length file.flush end end end end def run1 @count.times do |i| @ractor1.send("Message #{i + 1}") end @ractor1.join end def run2 @count.times do |i| @ractor2.send("Message #{i + 1}") end @ractor2.join end end records = 1_000_000 test = RactorsTest.new(records) p [:once, Benchmark.realtime { test.run1 }.round(2)] p [:all, Benchmark.realtime { test.run2 }.round(2)] ``` **Benchmark Results** On my system, receive_all shows ~4x improvement over individual receive: **Key Observations:** Ractor1 (using receive): Processes each message individually, resulting in frequent I/O calls. Ractor2 (using receive_all): Processes all queued messages at once, minimizing I/O overhead -- https://bugs.ruby-lang.org/

4 12