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

[ruby-core:124956] [Ruby Misc#21949] timeout gem maintainer
by Eregon (Benoit Daloze) 09 Mar '26

09 Mar '26

Issue #21949 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21949: timeout gem maintainer https://bugs.ruby-lang.org/issues/21949 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The timeout has currently [no official active maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md). I would like to propose myself as maintainer of the [timeout](https://github.com/ruby/timeout) gem. I basically rewrote the implementation in https://github.com/ruby/timeout/pull/15 and acted as a maintainer since then by reviewing PRs and replying to issues. I also recently solved all open issues except https://github.com/ruby/timeout/issues/52 (where I have a draft PR to try to solve it and need more time to validate the fix). Among other [recent active contributors](https://github.com/ruby/timeout/graphs/contributors) I see @nobu, would you like to be maintainer of timeout as well? -- https://bugs.ruby-lang.org/

2 8

[ruby-core:123992] [Ruby Bug#21760] Ruby::Box: a couple of require-related problems
by zverok (Victor Shepelev) 09 Mar '26

09 Mar '26

Issue #21760 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21760: Ruby::Box: a couple of require-related problems https://bugs.ruby-lang.org/issues/21760 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: 4.0.0dev (2025-12-03T05:16:03Z master 4762f429f4) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am not sure whether all the problems have the same nature, but putting them together for now. **1. Enabling box breaks `gem`+`require`** Minimal reproducible example: `test.rb`: ```ruby gem 'faraday', '= 2.14.0' require 'faraday' p Faraday::VERSION ``` (Note that there is no explicit use of `Ruby::Box`) Running it with and without `RUBY_BOX`: ```sh $ ruby test.rb "2.14.0" $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' ``` (sic, the error is printed twice) **2. requiring the same gem from `Box`-loaded file and the main file** `box.rb`: ```ruby require 'faraday' p "In a box: #{Faraday::VERSION}" ``` `main.rb` ```ruby b = Ruby::Box.new b.load('box.rb') require 'faraday' ``` ```sh $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. "In a box: 2.14.0" main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' ``` **3. `Box#require` seem to not be aware of gems** In the example above, we see that Box-loaded file can require a gem. This also works: ```ruby b = Ruby::Box.new b.eval(<<~RUBY) require "faraday" p Faraday::VERSION RUBY ``` (prints "2.14.0" as expected) But this doesn't: ```ruby b = Ruby::Box.new b.require('faraday') ``` ```sh $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. test.rb:3:in 'Ruby::Box#require': cannot load such file -- faraday (LoadError) from test.rb:3:in '<main>' ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124741] [Ruby Bug#21873] `UnboundMethod#==` returns false for methods obtained via extend + unbind
by mdalessio (Mike Dalessio) 07 Mar '26

07 Mar '26

Issue #21873 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #21873: `UnboundMethod#==` returns false for methods obtained via extend + unbind https://bugs.ruby-lang.org/issues/21873 * Author: mdalessio (Mike Dalessio) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description `UnboundMethod#==` returns `false` when comparing a module's instance method against the same method obtained via `Method#unbind` on a class that includes or extends that module, despite having the same owner and source location. ```ruby module MyMethods def hello = "hello" end class Base extend MyMethods end from_module = MyMethods.instance_method(:hello) from_unbind = Base.method(:hello).unbind p from_module.owner == from_unbind.owner #=> true p from_module.source_location == from_unbind.source_location #=> true p from_module.inspect == from_unbind.inspect #=> true p from_module == from_unbind #=> false (expected true) ``` ## Diagnosis `method_eq` compares method entries using `method_entry_defined_class`. For methods mixed in via `include`/`extend`, the "defined class" will be an ICLASS and not the original class/module. In the example above, `method_eq` is comparing a module's ICLASS entry against the module, and that will always be false. Related: #18798 (fixed by @ko1 in 59e389af). -- https://bugs.ruby-lang.org/

6 6

[ruby-core:124673] [Ruby Bug#21860] Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup`
by byroot (Jean Boussier) 07 Mar '26

07 Mar '26

Issue #21860 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21860: Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup` https://bugs.ruby-lang.org/issues/21860 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We recently observed some deadlocked processes. These got deadlock during child initialization right after `Process.fork`. Based on the `gdb` session, the child is deadlocked in `threadptr_interrupt_exec_cleanup`, which suggest `th->interrupt_lock` was locked by another thread in the parent, and wasn't reinitialized in the children before calling `threadptr_interrupt_exec_cleanup`. ```c (gdb) bt 20 #0 0x0000ffff855a09c0 in __lll_lock_wait () from /lib64/libc.so.6 #1 0x0000ffff855a6d60 in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/libc.so.6 #2 0x0000aaaaaeec04c8 [PAC] in rb_native_mutex_lock (lock=<optimized out>) at /ruby-3.4.4/thread_pthread.c:116 #3 threadptr_interrupt_exec_cleanup (th=<optimized out>) at thread.c:6052 #4 thread_cleanup_func_before_exec (th_ptr=0xffff35803000) at thread.c:514 #5 thread_cleanup_func (atfork=1, th_ptr=0xffff35803000) at thread.c:524 #6 terminate_atfork_i (current_th=0xffff84e1e000, th=0xffff35803000) at thread.c:4769 #7 rb_thread_atfork_internal (atfork=<optimized out>, th=0xffff84e1e000) at thread.c:4736 #8 rb_thread_atfork () at thread.c:4779 #9 0x0000aaaaaee110fc [PAC] in after_fork_ruby (pid=0) at process.c:1693 #10 rb_fork_ruby (status=status@entry=0x0) at process.c:4253 #11 0x0000aaaaaee11154 [PAC] in proc_fork_pid () at process.c:4266 #12 rb_proc__fork (_obj=<optimized out>) at process.c:4313 #13 0x0000aaaaaeefeb7c [PAC] in vm_call_cfunc_with_frame_ (stack_bottom=0xffff84e7a1c8, argv=0xffff84e7a1d0, argc=0, calling=<optimized out>, reg_cfp=0xffff84f79150, ec=0xffff84e31050) at /ruby-3.4.4/vm_insnhelper.c:3794 #14 vm_call_cfunc_with_frame (ec=0xffff84e31050, reg_cfp=0xffff84f79150, calling=<optimized out>) at /ruby-3.4.4/vm_insnhelper.c:3840 #15 0x0000aaaaaef1aa44 [PAC] in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /ruby-3.4.4/vm_callinfo.h:415 #16 vm_exec_core (ec=0xffff84e31050) at /ruby-3.4.4/insns.def:1063 #17 0x0000aaaaaef0aa58 [PAC] in rb_vm_exec (ec=ec@entry=0xffff84e31050) at vm.c:2595 #18 0x0000aaaaaef0fe48 [PAC] in vm_call0_body (ec=ec@entry=0xffff84e31050, calling=calling@entry=0xffffea5a1e78, argv=argv@entry=0x0) at /ruby-3.4.4/vm_eval.c:225 #19 0x0000aaaaaef136e8 in vm_call0_cc (kw_splat=0, cc=0xfffeee654508, argv=<optimized out>, argc=0, id=27393, recv=281472906794680, ec=0xffff84e31050) at /ruby-3.4.4/vm_eval.c:101 ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124699] [Ruby Bug#21866] Backport Fix for integer overflow checks in enumerator
by rwstauner (Randy Stauner) 07 Mar '26

07 Mar '26

Issue #21866 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #21866: Backport Fix for integer overflow checks in enumerator https://bugs.ruby-lang.org/issues/21866 * Author: rwstauner (Randy Stauner) * Status: Open * Assignee: rwstauner (Randy Stauner) * Target version: 4.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- I would like to backport this PR https://github.com/ruby/ruby/pull/15829 that has already merged to master. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 07 Mar '26

07 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124928] [Ruby Feature#21943] Add StringScanner#get_int to extract capture group as Integer without intermediate String
by jinroq (Jinroq SAITOH) 06 Mar '26

06 Mar '26

Issue #21943 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21943: Add StringScanner#get_int to extract capture group as Integer without intermediate String https://bugs.ruby-lang.org/issues/21943 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- ## Motivation The date library is being [rewritten from C to pure Ruby](https://github.com/ruby/date/pull/155). During this effort, `Date._strptime` was identified as a major performance bottleneck. Profiling revealed that the root cause is the overhead of extracting capture groups as Strings and then converting them to Integers: ``` sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i # allocates String "2024", converts to Integer, discards String mon = sc[2].to_i # allocates String "06", converts to Integer, discards String mday = sc[3].to_i # allocates String "15", converts to Integer, discards String ``` Each `sc[n].to_i` call allocates a temporary String object that is immediately discarded. When parsing dates, only the integer values are needed — the intermediate Strings serve no purpose. In the C implementation of date, matched byte ranges are converted directly to integers without any String allocation. The pure Ruby version cannot do this with the current StringScanner API. ## Proposal Add `StringScanner#get_int(index`) that returns the captured substring at the given index as an Integer, converting directly from the matched byte range at the C level without allocating an intermediate String object. ``` scanner = StringScanner.new("2024-06-15") scanner.scan(/(\d{4})-(\d{2})-(\d{2})/) scanner.get_int(1) # => 2024 scanner.get_int(2) # => 6 scanner.get_int(3) # => 15 ``` It returns `nil` in the same cases where `scanner[index]` would return `nil` (no match, index out of range, optional group did not participate). ## Use case The primary use case is `Date._strptime` in the pure Ruby date library. The fast path for `%Y-%m-%d` format currently does: ``` # Current: 3 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i mon = sc[2].to_i mday = sc[3].to_i ``` With `get_int`: ``` # Proposed: 0 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc.get_int(1) mon = sc.get_int(2) mday = sc.get_int(3) ``` This pattern appears throughout `_strptime` for every date/time component (`%H`, `%M`, `%S`, `%m`, `%d`, etc.), so the cumulative impact is significant. ## Benchmark Environment: Ruby 4.0.1, x86_64-linux | Operation | i/s | per iteration | Comparison | | :--- | :--- | :--- | :--- | | **sc.get_int(n)** | 1,029,041.7 | 971.78 ns/i | (Reference) | | **sc[n].to_i** | 791,945.6 | 1.26 μs/i | 1.30x slower | `get_int` is 1.30x faster than `sc[n].to_i` for a typical date parsing scenario (3 capture groups). The improvement comes from eliminating 3 temporary String allocations per call. In the context of `Date._strptime("%Y-%m-%d")`, this overhead is a significant portion of the total parse time, as shown in earlier profiling: | Operation | Time | | :--- | :--- | | C ext `_strptime` (reference) | 408 ns | | SC.new + scan + captures + `.to_i` x3 | 1,210 ns | | Pure Ruby `_strptime_ymd` total | 1,290 ns | The capture extraction + `.to_i` conversion accounts for roughly 40% of the total parse time. `get_int` directly reduces this portion. ## Implementation A working implementation is available. It reuses the same index resolution logic as `StringScanner#[]` (including negative indices) but calls `rb_cstr2inum` on the matched byte range instead of `extract_range`, avoiding String object allocation entirely. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124933] [Ruby Bug#21944] "Cannot allocate memory" with M:N threads or Ractors on a low RAM Linux machine
by jhawthorn (John Hawthorn) 05 Mar '26

05 Mar '26

Issue #21944 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21944: "Cannot allocate memory" with M:N threads or Ractors on a low RAM Linux machine https://bugs.ruby-lang.org/issues/21944 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- Linux default overcommit policy (`vm.overcommit_memory=0`) will fail for allocations which are "obvious overcommits" (https://www.kernel.org/doc/html/latest/mm/overcommit-accounting.html) Under M:N threading (including under Ractors) we allocate a ~512MB section of RAM to use (the physical pages are lazily mapped in when used). This caused the following exception on a machine with <512 MB of RAM. ``` Thread#initialize': can't create Thread: Cannot allocate memory (ThreadError) ``` This can be solved by initially mapping the region of memory in as protected, and only enabling read/write the first time a stack is used. We already added a guard page the first time a stack was used, so this just inverts that mprotect call (it also makes two calls instead of one, but since these are only used the first time a stack is used, I think that simplicity is worth the extra syscall). https://github.com/ruby/ruby/pull/16232 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124895] [Ruby Feature#21930] Add Ractor#empty? method to check for pending messages without blocking
by synacker (Mikhail Milovidov) 05 Mar '26

05 Mar '26

Issue #21930 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21930: Add Ractor#empty? method to check for pending messages without blocking https://bugs.ruby-lang.org/issues/21930 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** In concurrent Ractor‑based architectures, there’s a critical need to check whether a Ractor has pending messages without blocking. Currently, this is not possible with the standard API **Motivation** The Ractor API provides a powerful mechanism for communication between system OS threads. However, in high‑load systems that use cooperative multitasking, the current Ractor#receive method presents limitations: * It blocks the current thread until a message arrives. * It doesn’t offer a non‑blocking way to check the message queue. * This makes it difficult to integrate Ractors with cooperative scheduling frameworks (e.g., Async, Fiber‑based systems). As a result, developers must either: * Accept thread blocking (hurting responsiveness). * Implement complex workarounds with timeouts or auxiliary queues. **Proposed solution** Add Ractor#empty? to the Ractor API. The method should: * Return true if there are no pending messages in the Ractor’s main queue. * Return false if there is at least one message available for processing. * Not block the calling thread under any circumstances. * Be safe to call from any Ractor (including the current one). **Demonstration code** Below is a proof‑of‑concept showing how Ractor#empty? enables cooperative multitasking with the Async gem: ``` require 'async' class TimeCommand attr_reader :id def initialize(id) @id = id end def task 1.upto(3) do |i| sleep(1) puts "[cmd #{@id}] step #{i} @ #{Time.now}" end end end class Worker def initialize @ractor = Ractor.new do loop do Sync do |task| in_queue = Async::Queue.new queue_task = task.async do |subtask| while command = in_queue.dequeue subtask.async do |child_task| command.task end end end task.async(transient: true) do |main_task| loop do commands = [] if queue_task.children? || !in_queue.empty? main_task.yield commands.append Ractor.receive while !Ractor.current.empty? else commands.append Ractor.receive end unless commands.empty? puts "Worker received batch of #{commands.size} commands." commands.each { |command| in_queue.enqueue(command) } end end end end end end end def send(command) @ractor.send(command, move: true) end def wait @ractor.join end end worker = Worker.new 1000.times do |i| 100.times do |j| worker.send TimeCommand.new(i * 10 + j) end sleep(1) end worker.wait ``` **Key observations:** With Ractor#empty?, developers can: * Integrate Ractors with cooperative multitasking frameworks (e.g., Async) more naturally. * Avoid thread blocking when checking for incoming messages. * Batch process messages efficiently (collect all pending messages in one go). * Improve responsiveness in high‑concurrency scenarios by yielding control back to the scheduler when no work is available. **Benefits** * Enables better integration with modern Ruby concurrency tools. * Reduces need for complex workarounds. * Improves performance in message‑driven architectures. * Maintains Ractor’s thread‑safety guarantees. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:124924] [Ruby Feature#21942] Allow reading class variables from non-main Ractors
by tenderlovemaking (Aaron Patterson) 05 Mar '26

05 Mar '26

Issue #21942 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21942: Allow reading class variables from non-main Ractors https://bugs.ruby-lang.org/issues/21942 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- It's very common in Rails applications to use class variables, and today class variables aren't even allowed to be read inside a Ractor: ```ruby class Foo # This is NOT allowed to be read in non-main Ractors @@bar = 123 def self.bar; @@bar; end # This is allowed to be read in non-main Ractors @baz = 123 def self.baz; @baz; end end # This is OK Ractor.new { p Foo.baz }.value # Exception here Ractor.new { p Foo.bar }.value ``` Output is like this: ``` test.rb:4:in 'Foo.bar': can not access class variables from non-main Ractors (@@bar from Foo) (Ractor::IsolationError) from test.rb:10:in 'block in <main>' ``` Can we allow shareable values to cross the Ractor boundary, similar to class instance variables? Just for reference, the Rails code in question is [here](https://github.com/rails/rails/blob/371cbc9711b0b1fdadc186739c507b88e…. -- https://bugs.ruby-lang.org/

1 1