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

[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

[ruby-core:125518] [Ruby Bug#22072] [BUG] should have cvar cache entry
by rmosolgo (Robert Mosolgo) 22 May '26

22 May '26

Issue #22072 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #22072: [BUG] should have cvar cache entry https://bugs.ruby-lang.org/issues/22072 * Author: rmosolgo (Robert Mosolgo) * 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! I have a CI build for my project that runs on Ruby 4.0.4, and it has recently started _sometimes_ segfaulting with this error: "". I have seen failures in two different spots: - In the middle of tests: ``` /home/runner/work/graphql-ruby/graphql-ruby/vendor/bundle/ruby/4.0.0/gems/liquid-4.0.4/lib/liquid/strainer.rb:43: [BUG] should have cvar cache entry ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] ``` https://github.com/rmosolgo/graphql-ruby/actions/runs/25750012675/job/75623… - At the very beginning of the suite: ``` # Running tests with run options --seed 45415: /home/runner/work/graphql-ruby/graphql-ruby/spec/graphql/dataloader_spec.rb:1515: warning: Scheduler should implement #fiber_interrupt /home/runner/work/graphql-ruby/graphql-ruby/spec/graphql/schema/ractor_shareable_spec.rb:54: warning: Ractor API is experimental and may change in future versions of Ruby. /home/runner/work/graphql-ruby/graphql-ruby/vendor/bundle/ruby/4.0.0/gems/railties-8.1.3/lib/rails/generators.rb:27: [BUG] should have cvar cache entry ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] ``` https://github.com/rmosolgo/graphql-ruby/actions/runs/25922299759/job/76194… I have attached the full crash messages to this issue. I don't have any guesses what to do next with these errors, but I thought I'd report them in case they're helpful. I'm happy to debug with my project if there's anything I can do to help. For now, I can get it to pass by re-running the build. Thanks! Robert ---Files-------------------------------- dump1.txt (15.9 KB) dump2.txt (78.3 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125546] [Ruby Bug#22075] heap-use-after-free in `rb_vm_ci_lookup` under parallel Ractors
by zonuexe (Kenta USAMI) 21 May '26

21 May '26

Issue #22075 has been reported by zonuexe (Kenta USAMI). ---------------------------------------- Bug #22075: heap-use-after-free in `rb_vm_ci_lookup` under parallel Ractors https://bugs.ruby-lang.org/issues/22075 * Author: zonuexe (Kenta USAMI) * Status: Open * ruby -v: 4.0.5 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Environment - `ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [aarch64-linux]` - Also reproduced on `ruby 4.0.4 ... [x86_64-linux]`. ## Summary Under a parallel Ractor pool, a GC sweep on one Ractor frees a `T_DATA` object while `rb_vm_ci_lookup` on another Ractor reads that freed heap memory. Pure-Ruby code triggers it; the VM crashes (SIGSEGV). ## Reproduction No minimal script isolated yet. Reproduced with the `rigor` project at tag `v0.1.7` (https://github.com/rigortype/rigor/tree/v0.1.7) 1. Build Ruby + native gems with AddressSanitizer: ``` ./configure --disable-yjit \ cflags="-fsanitize=address -fno-sanitize-address-use-after-scope -g -O1" \ cppflags="-fsanitize=address" LDFLAGS="-fsanitize=address" ``` 2. Run a spec that drives a 2-worker Ractor pool: ``` ASAN_OPTIONS="detect_leaks=0 detect_stack_use_after_return=0 halt_on_error=0" \ RIGOR_INCLUDE_RACTOR_POOL=1 \ bundle exec rspec spec/rigor/analysis/runner_pool_spec.rb ``` CI failure: https://github.com/rigortype/rigor/actions/runs/26123249293/job/76830355801 ## Expected Pure-Ruby code on a Ractor pool runs to completion or raises a Ruby exception. It does not corrupt the heap. ## Actual SIGSEGV (≈70% of runs without a sanitizer; crash site varies). AddressSanitizer (Ruby 4.0.5, aarch64-linux, 3 Ractors): ``` ERROR: AddressSanitizer: heap-use-after-free READ of size 4 rb_vm_ci_lookup vm_method.c:699 vm_ci_new_ vm_callinfo.h:219 vm_ci_new_runtime_ vm_callinfo.h:240 vm_search_super_method vm_insnhelper.c:5152 (a Ruby `super` call) freed by: rb_gc_impl_free gc/default/default.c:8279 rb_data_free gc.c:1205 rb_gc_obj_free gc.c:1351 gc_sweep_plane gc/default/default.c:3510 previously allocated by: rb_data_typed_object_zalloc gc.c:1131 rbs_new_location2 (rbs gem C extension) SUMMARY: AddressSanitizer: heap-use-after-free vm_method.c:699 in rb_vm_ci_lookup ``` The same line also surfaces as `heap-buffer-overflow`. Original CI `[BUG]` (Ruby 4.0.4, x86_64-linux), same path: ``` [BUG] Segmentation fault vm_ci_hash <- rb_st_update <- rb_vm_ci_lookup (vm_method.c:712) <- vm_ci_new_runtime_ <- vm_search_super_method Total ractor count: 5 ``` ## Notes - ThreadSanitizer reports nothing — it cannot follow the M:N scheduler. - Both ASAN stacks show `thread T0` because the M:N scheduler multiplexes Ractors onto native threads; the run uses 3 Ractors. - The free path is a plain GC sweep (`gc_sweep_plane` → `rb_data_free`), no finalizer. ## Related issues - #21200 — parallel Ractor spurious segfault/hang; root cause unidentified. Possibly the same class of bug. - #21204 — same class of heap corruption, but scoped to MMTk GC. This report reproduces it on the **default GC**. -- https://bugs.ruby-lang.org/

3 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) 21 May '26

21 May '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 1

[ruby-core:125551] [Ruby Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 20 May '26

20 May '26

Issue #16012 has been updated by Eregon (Benoit Daloze). That's great! ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-117376 * Author: MSP-Greg (Greg L) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124594] [Ruby Bug#21844] Inconsistent ArgumentError message for Data::define.new
by jnchito (Junichi Ito) 20 May '26

20 May '26

Issue #21844 has been reported by jnchito (Junichi Ito). ---------------------------------------- Bug #21844: Inconsistent ArgumentError message for Data::define.new https://bugs.ruby-lang.org/issues/21844 * Author: jnchito (Junichi Ito) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The code below shows `Data::define.new` treats symbol and string keys equivalently: ``` ruby C = Data.define(:a, :b) C.new(a: 1, b: 1) #=> #<data C a=1, b=1> C.new('a' => 1, 'b' => 1) #=> #<data C a=1, b=1> ``` But it acts differently when detecting missing keywords: ```ruby C.new(a: 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) C.new('a' => 1) #=> 'Data#initialize': missing keywords: :a, :b (ArgumentError) ``` I feel it should work like this: ```ruby C.new('a' => 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) ``` I created a PR to fix it: https://github.com/ruby/ruby/pull/15910 -- https://bugs.ruby-lang.org/

6 14