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

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

05 Jun '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/

8 17

[ruby-core:125562] [Ruby Bug#22078] mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4
by hsbt (Hiroshi SHIBATA) 02 Jun '26

02 Jun '26

Issue #22078 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22078: mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4 https://bugs.ruby-lang.org/issues/22078 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: DONTNEED ---------------------------------------- On mswin builds, `win32/Makefile.sub` builds `XCFLAGS` without `XINCFLAGS`, so the include path written by `configure.bat --with-opt-dir=...` never reaches `cl.exe` and `#include <gmp.h>` cannot be resolved. `master` and `ruby_4_0` are fixed by https://github.com/ruby/ruby/commit/13c64a8a20, but neither `ruby_3_4` nor `ruby_3_3` has it. How it surfaces differs between the two: - `ruby_3_4`: `win32/setup.mak` auto-enables GMP whenever gmp is present, so the build tries to use it and fails on the missing `gmp.h`. - `ruby_3_3`: `win32/setup.mak` only enables GMP when `--with-gmp` is explicitly passed. Without the flag the build passes but GMP is never used; with the flag, it fails the same way as 3.4. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125592] [Ruby Bug#22087] Octal format specifier in alternatve form ignores zero precision if value is zero
by Earlopain (Earlopain _) 31 May '26

31 May '26

Issue #22087 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22087: Octal format specifier in alternatve form ignores zero precision if value is zero https://bugs.ruby-lang.org/issues/22087 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-29T14:34:40Z master 7a07a54298) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- For integer types, it is documented that zero as a value results in empty output: https://docs.ruby-lang.org/en/4.0/language/format_specifications_rdoc.html#… This applies when `#` is not given. But with `#`, the octal format violates that statement: ```rb pp sprintf("%#.0b", 0) # => "" pp sprintf("%#.0B", 0) # => "" pp sprintf("%#.0x", 0) # => "" pp sprintf("%#.0X", 0) # => "" pp sprintf("%#.0o", 0) # => "0" ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125581] [Ruby Bug#22084] invokesuper from define_method in Ractor can call wrong super method or crash
by jhawthorn (John Hawthorn) 27 May '26

27 May '26

Issue #22084 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22084: invokesuper from define_method in Ractor can call wrong super method or crash https://bugs.ruby-lang.org/issues/22084 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: ractor * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `vm_search_super_method` has an odd behaviour where it allocates new callinfo (ci) and assigns it back to the iseq. All of our other method calls only reassign the callcache (cc). Because this CI is used from the iseq immediately after for method lookup or even later for the name in method_missing. ```ruby N = Integer(ENV.fetch("N", "1000000")) class Base def method_missing(mid, *) = mid end class Child < Base BODY = Ractor.shareable_proc { super() } define_method(:foo, &BODY) define_method(:bar, &BODY) end [:foo, :bar].map do |mid| Ractor.new(mid) do |mid| obj = Child.new N.times do got = obj.__send__(mid) raise "#{mid} returned #{got.inspect}" unless got == mid end end end.each(&:value) ``` ``` N = Integer(ENV.fetch("N", "1000000")) class Base def foo = :foo def bar = :bar end class Child < Base BODY = Ractor.shareable_proc { super() } define_method(:foo, &BODY) define_method(:bar, &BODY) end [:foo, :bar].map do |mid| Ractor.new(mid) do |mid| obj = Child.new N.times do got = obj.__send__(mid) raise "#{mid} returned #{got.inspect}" unless got == mid end end end.each(&:value) ``` Both of these will eventually result in the wrong parent method being called (or method_missing with the wrong name). Less often they may also segfault. https://github.com/ruby/ruby/pull/17127 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125579] [Ruby Bug#22083] "should have cvar cache entry" bug on Array#clone
by chucke (Tiago Cardoso) 27 May '26

27 May '26

Issue #22083 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22083: "should have cvar cache entry" bug on Array#clone https://bugs.ruby-lang.org/issues/22083 * Author: chucke (Tiago Cardoso) * Status: Open * 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 ---------------------------------------- The [httpx test suite has been reliably failing with a core dump on latest ruby 4](https://gitlab.com/os85/httpx/-/jobs/14559355119). The test suite runs on minitest with parallel mode turned on, although the issue can be reproduced in serial mode. The error happens when running the ssh proxy test, which eventually calls [this net-ssh function](https://github.com/net-ssh/net-ssh/blob/v7.3.2/lib/net/ssh/config… and produces the core dump sent in attachment. I couldn't come up with reproduction not involving the httpx test suite docker setup, but I was able to narrow it down. [Here](https://gitlab.com/os85/httpx/-/blob/master/test/README.md?ref_type=h… are instructions on how to set up the docker container. You can then run this script to reproduce it: ```ruby require "httpx" uri = "http://nghttp2/get" Ractor.new(uri) do |uri| HTTPX.get(uri) end.value sess = HTTPX.plugin(:"proxy/ssh") .with_proxy(uri: ["ssh://sshproxy:22"], username: "root", auth_methods: %w[publickey], host_key: "ssh-rsa", keys: %w[test/support/ssh/ssh_host_ed25519_key]) ``` The key information is ractors being used before. ---Files-------------------------------- test.log (167 KB) -- https://bugs.ruby-lang.org/

2 1

[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: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