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

[ruby-core:125599] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by Impotency6272 (kai matsudate) 01 Jun '26

01 Jun '26

Issue #22089 has been reported by Impotency6272 (kai matsudate). ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089 * Author: Impotency6272 (kai matsudate) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/

1 0

[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) 28 May '26

28 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

[ruby-core:125466] [Ruby Bug#22064] GC compaction breaks compare-by-identity sets
by peterzhu2118 (Peter Zhu) 22 May '26

22 May '26

Issue #22064 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #22064: GC compaction breaks compare-by-identity sets https://bugs.ruby-lang.org/issues/22064 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/16923 Compare-by-identity sets use the address for hashing, so we must pin it so the object does not move in GC compaction. Objects in a compare-by-identity set is not currently pinned, causing the set to be broken if the object is moved. For example: ```ruby set = Set.new.compare_by_identity o = Object.new set.add(o) puts set.include?(o) GC.verify_compaction_references(expand_heap: true, toward: :empty) puts set.include?(o) ``` It should output true twice, but it outputs true and false. -- https://bugs.ruby-lang.org/

2 1