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

[ruby-core:125083] [Ruby Misc#21960] Improve #backtrace to not confuse terminals
by svoop (Sven Schwyn) 25 May '26

25 May '26

Issue #21960 has been reported by svoop (Sven Schwyn). ---------------------------------------- Misc #21960: Improve #backtrace to not confuse terminals https://bugs.ruby-lang.org/issues/21960 * Author: svoop (Sven Schwyn) * Status: Open ---------------------------------------- The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case `/path/to/whatever.rb:8:in`. This is then used as an argument to `open` (on macOS) which will not work due to the `:in` part. There are two ways to improve this: ## Replace the colon with a space Given the existence of `#backtrace_locations` which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the `#backtrace` to look like this: ``` /path/to/whatever.rb:8 in `/' /path/to/whatever.rb:8 in `show' (...) ^^^ space instead of colon ``` ## Add OCS 8 sequences [OCS 8](https://github.com/Alhadis/OSC8-Adoption) are the `<a>` tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument. -- https://bugs.ruby-lang.org/

7 16

[ruby-core:125373] [Ruby Bug#22017] Backport win32-resolv
by nobu (Nobuyoshi Nakada) 24 May '26

24 May '26

Issue #22017 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22017: Backport win32-resolv https://bugs.ruby-lang.org/issues/22017 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: UNKNOWN ---------------------------------------- The win32-resolv library bundled with ruby 3.4 is half-baked 0.6.2. It should be updated to 0.6.3 at least, hopefully 0.7.1. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125572] [Ruby Bug#22080] `Integer(obj, exception: false)` raises when `to_str` doesn't return String
by Earlopain (Earlopain _) 23 May '26

23 May '26

Issue #22080 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22080: `Integer(obj, exception: false)` raises when `to_str` doesn't return String https://bugs.ruby-lang.org/issues/22080 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-23T13:04:55Z master 6c6df00bbc) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb obj = Object.new def obj.to_str = 1 Integer(obj, exception: false) # can't convert Object to String (Object#to_str gives Integer) (TypeError) ``` But returning the wrong type from `to_int` is fine: ```rb obj = Object.new def obj.to_int = "1" Integer(obj, exception: false) # nil ``` Doc says this (https://docs.ruby-lang.org/en/master/Kernel.html#method-i-Integer) > With exception given as false, an exception of any kind is suppressed and nil is returned. So it looks like it should not raise in both cases. Or more specifically, try `to_i` next, since that is what happens when `to_int` returns the wrong type. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125565] [Ruby Bug#22079] Float#ceil gives incorrect result
by cryptogopher (crypto gopher) 23 May '26

23 May '26

Issue #22079 has been reported by cryptogopher (crypto gopher). ---------------------------------------- Bug #22079: Float#ceil gives incorrect result https://bugs.ruby-lang.org/issues/22079 * Author: cryptogopher (crypto gopher) * Status: Open * ruby -v: ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Let's take following number as an example: ``` ruby > Float::MIN => 2.2250738585072014e-308 ``` This gives proper result: ```ruby > Float::MIN.ceil(308) => 2.9999999999999997e-308 ``` But this does not: ```ruby > Float::MIN.floor(309) => NaN ``` even though the result is perfectly valid `Float` number: ```ruby > "2.3e-308".to_f => 2.3e-308 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125045] [Ruby Bug#21955] `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page`
by ioquatix (Samuel Williams) 23 May '26

23 May '26

Issue #21955 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21955: `Fiber#transfer`: machine stack not released when fiber terminates, causing `FiberError: can't set a guard page` https://bugs.ruby-lang.org/issues/21955 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a fiber terminates (falls off the end of its block, or raises an unhandled exception) after being reached via `Fiber#transfer`, its machine stack is **not** returned to the fiber pool. The stack is only freed when the `Fiber` object is eventually garbage collected. In production, where GC does not run continuously, terminated fibers accumulate unreleased stacks. Each stack allocation contains a guard page set with `mprotect(PROT_NONE)`, which splits a kernel VMA. On Linux this exhausts the per-process `vm.max_map_count` limit and raises: ``` FiberError: can't set a guard page: Cannot allocate memory ``` The symptom is confusing: the fibers are all dead (`alive? == false`), new fibers cannot be created, but GC has not run. ## Root cause In `cont.c`, `fiber_switch()`, the eager stack release after `fiber_store` returns is guarded by `resuming_fiber`: ```c // cont.c (affected versions) #ifndef COROUTINE_PTHREAD_CONTEXT if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` `resuming_fiber` is only non-`NULL` when the switch was initiated by `Fiber#resume` (which passes `resuming_fiber = fiber`). `Fiber#transfer` passes `resuming_fiber = NULL`, so the condition is never true and the stack is silently leaked until GC. Additionally, `fiber_raise` on a suspended non-yielding (transferred) fiber calls `fiber_transfer_kw`, also passing `resuming_fiber = NULL`, so the same leak occurs when a transferred fiber is terminated by a raised exception. ## Reproduction Set a low map count limit, then run the attached script: ``` sudo bash -c "echo 10000 > /proc/sys/vm/max_map_count" ruby test_fiber_transfer_leak.rb ``` Restore afterwards (`sysctl vm.max_map_count` shows the default, typically 65530). ```ruby GC.disable leaked = [] count = 0 begin 10_000.times do f = Fiber.new { } # terminates immediately leaked << f # hold reference so Fiber object is not GC'd f.transfer # transfer, not resume => stack NOT released (bug) count += 1 puts "[#{count} fibers] all dead: #{leaked.none?(&:alive?)}" if count % 1000 == 0 end puts "No error — fix is applied." rescue FiberError => e puts "FiberError after #{count} fibers: #{e.message}" puts "All terminated (alive?=false): #{leaked.none?(&:alive?)}" ensure GC.enable leaked.clear GC.start end ``` Expected output on **unpatched** Ruby (vm.max_map_count=10000): ``` [1000 fibers] all dead: true [2000 fibers] all dead: true [3000 fibers] all dead: true [4000 fibers] all dead: true FiberError after 4096 fibers: can't set a guard page: Cannot allocate memory All terminated (alive?=false): false ``` Expected output on **patched** Ruby: ``` [1000 fibers] all dead: true ... [10000 fibers] all dead: true No error — fix is applied. ``` ## Fix Drop the `resuming_fiber &&` guard. After `fiber_store` returns we are executing in the caller's context — we are never on `fiber`'s stack — so releasing it is unconditionally safe. `fiber_stack_release` is already idempotent (guarded by `fiber->stack.base == NULL`), so the resume path is unaffected. ```c #ifndef COROUTINE_PTHREAD_CONTEXT if (FIBER_TERMINATED_P(fiber)) { RB_VM_LOCKING() { fiber_stack_release(fiber); } } #endif ``` Pull request with fix: https://github.com/ruby/ruby/pull/16416 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125099] [Ruby Bug#21961] Marshal.load freeze option fail to free linked strings
by byroot (Jean Boussier) 23 May '26

23 May '26

Issue #21961 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21961: Marshal.load freeze option fail to free linked strings https://bugs.ruby-lang.org/issues/21961 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- ```ruby str = "test" arr = [str, str] strings = Marshal.load(Marshal.dump(arr), freeze: true) p strings.map(&:frozen?) # => [true, false] ``` Expected: `[true, true]` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125078] [Ruby Bug#21959] rb_internal_thread_event_hooks_rw_lock is not reinitialized after fork causing deadlocks
by anmarchenko_datadog (Andrey Marchenko) 23 May '26

23 May '26

Issue #21959 has been reported by anmarchenko_datadog (Andrey Marchenko). ---------------------------------------- Bug #21959: rb_internal_thread_event_hooks_rw_lock is not reinitialized after fork causing deadlocks https://bugs.ruby-lang.org/issues/21959 * Author: anmarchenko_datadog (Andrey Marchenko) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby's GVL Instrumentation API uses a read-write lock (rb_internal_thread_event_hooks_rw_lock) to protect the list of thread event hooks: - Read lock — acquired on every GVL transition to iterate and call hook callbacks (rb_thread_execute_hooks) - Write lock — acquired when adding/removing hooks (rb_internal_thread_add_event_hook, rb_internal_thread_remove_event_hook) After fork(), Ruby reinitializes several internal locks (e.g. vm->ractor.sched.lock, timer_th.waiting_lock), but not rb_internal_thread_event_hooks_rw_lock. This wasn't added with the GVL Instrumentation API. The full reproducer is available here: https://github.com/anmarchenko/ruby-locks-fork-bug ## Deadlock sequence 1. Parent process has thread event hooks registered (e.g. by a profiler like dd-trace-rb) 2. Multiple threads run concurrently, causing GVL transitions — each transition acquires a read lock on the rwlock 3. fork() happens while a thread holds the read lock 4. In the child, only the forking thread survives — the thread that held the lock is gone, but the lock state is copied as-is 5. Child tries to add or remove a hook → needs write lock → blocks forever on a lock that will never be released 6. Deadlock ## Impact This affects any Ruby C extension using the GVL Instrumentation API in combination with fork-based servers (Resque, Unicorn, Passenger, etc.). The original report comes from dd-trace-rb's profiler deadlocking Resque workers on Alpine Linux (musl libc): https://github.com/DataDog/dd-trace-rb/issues/4967 -- https://bugs.ruby-lang.org/

4 5

[ruby-core:125209] [Ruby Bug#21985] RubyVM::AST negative numbers do not include - in location
by kddnewton (Kevin Newton) 23 May '26

23 May '26

Issue #21985 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21985: RubyVM::AST negative numbers do not include - in location https://bugs.ruby-lang.org/issues/21985 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` irb(main):007> RubyVM::AbstractSyntaxTree.parse("-1") => (SCOPE@1:0-1:2 tbl: [] args: nil body: (INTEGER@1:1-1:2 -1)) irb(main):008> ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124887] [Ruby Bug#21926] Thread#value on popen3 wait thread hangs in finalizer
by stevecrozz (Stephen Crosby) 23 May '26

23 May '26

Issue #21926 has been reported by stevecrozz (Stephen Crosby). ---------------------------------------- Bug #21926: Thread#value on popen3 wait thread hangs in finalizer https://bugs.ruby-lang.org/issues/21926 * Author: stevecrozz (Stephen Crosby) * Status: Open * ruby -v: 3.3.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Calling Thread#value on an Open3.popen3 wait thread from a finalizer completes in Ruby 3.2 but hangs in Ruby 3.3+. See repro.rb below. When the Ruby process hangs in these conditions, it no longer responds to signals and it seems to be unable to run any other threads. This affects the schmooze gem (and potentially other code using Open3.popen3 with finalizers), causing test suites to hang intermittently. ``` ruby # repro.rb require 'open3' class ProcessWrapper def initialize @stdin, @stdout, @stderr, @wait_thread = Open3.popen3("cat") ObjectSpace.define_finalizer(self, self.class.make_finalizer(@stdin, @stdout, @stderr, @wait_thread)) end def self.make_finalizer(stdin, stdout, stderr, wait_thread) proc do stdin.close rescue nil stdout.close rescue nil stderr.close rescue nil wait_thread.value # Hangs here in Ruby 3.3+ end end end 100.times { ProcessWrapper.new } GC.stress = true 1000.times { Object.new } puts "done" ``` ## Environment - Linux x86_64 - Tested on Ruby 3.2.7, 3.3.7, 3.4.8 -- https://bugs.ruby-lang.org/

5 5

[ruby-core:125543] [Ruby Bug#22074] YJIT misaligns locals when there are > 256 local variables
by ibrahima (Ibrahim Awwal) 22 May '26

22 May '26

Issue #22074 has been reported by ibrahima (Ibrahim Awwal). ---------------------------------------- Bug #22074: YJIT misaligns locals when there are > 256 local variables https://bugs.ruby-lang.org/issues/22074 * Author: ibrahima (Ibrahim Awwal) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! We ran into this issue in production with a large Slim template in a Rails app, but we found that it's reproducible in any function with a lot of local variables. It seems like YJIT tracks local variables for register allocation in an 8-bit integer, so if there are more than 256 local variables in a function, the index overflows and maps back to the wrong variable and causes issues. We reproduced the issue with the released version of Ruby 4.0.4. We have a simple reproduction script and a proposed patch. The reproduction script generates some code with 257 locals and tests that it behaves correctly over multiple iterations (to exercise YJIT since it doesn't kick in right away). Full disclosure, the code is AI-written, and I don't know Rust, but I do know C and integer overflows, and it seems somewhat reasonable - though I'm not sure if it's the exact right fix. With YJIT disabled: ``` $ ruby yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] yjit=false iterations=100000 YJIT is not enabled. Re-run with: ruby --yjit yjit_many_locals_simple_repro.rb iteration=10000 iteration=20000 iteration=30000 iteration=40000 iteration=50000 iteration=60000 iteration=70000 iteration=80000 iteration=90000 iteration=100000 ok iterations=100000 ``` With YJIT enabled ``` $ ruby --yjit yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [x86_64-linux] yjit=true iterations=100000 failed_at=30 yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' ``` Thank you for your consideration! ---Files-------------------------------- yjit_many_locals_simple_repro.rb (1.32 KB) -- https://bugs.ruby-lang.org/

4 4