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

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

[ruby-core:125547] [Ruby Feature#16012] Add a (small) test-install suite?
by hsbt (Hiroshi SHIBATA) 20 May '26

20 May '26

Issue #16012 has been updated by hsbt (Hiroshi SHIBATA). I migrated snapshot package tests from ruby/actions to ruby/ruby repository. Now we test `make install` every pull reqeust with Linux, macOS and Windows. https://github.com/ruby/ruby/blob/master/.github/workflows/tarball-ubuntu.y… ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-117371 * 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:125534] [Ruby Bug#22073] Ruby 3.4.9 segfaults when loading native default gems compiled on Ubuntu 26.04 (GCC 15.2); Ruby 4.0.3 unaffected on same system
by taq (Eustaquio Rangel) 19 May '26

19 May '26

Issue #22073 has been reported by taq (Eustaquio Rangel). ---------------------------------------- Bug #22073: Ruby 3.4.9 segfaults when loading native default gems compiled on Ubuntu 26.04 (GCC 15.2); Ruby 4.0.3 unaffected on same system https://bugs.ruby-lang.org/issues/22073 * Author: taq (Eustaquio Rangel) * Status: Open * ruby -v: 3.4.9 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I'm reporting a reproducible issue on Ruby 3.4.9 on a freshly upgraded Ubuntu 26.04 LTS. Please let me know if you'd prefer this as a comment on #21655 instead. On Ubuntu 26.04 LTS, Ruby 3.4.9 produces unusable binaries when compiling current versions of native default gems (prism, cgi, date, io-console, rbs, and likely others). The versions of these gems that ship with the Ruby tarball work fine, but as soon as bundle install (or any gem install) compiles a newer version of them in the local environment, loading those gems segfaults or bus-errors immediately. Ruby 4.0.3 on the same machine, same toolchain, same Ubuntu installation does not exhibit this problem. My environment: OS: Ubuntu 26.04 LTS (Resolute Raccoon), upgraded today Kernel: 7.0.0-15-generic glibc: ldd (Ubuntu GLIBC 2.43-2ubuntu2) 2.43 System GCC: gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0 (default is GCC 15.2 on this release; GCC 14 also tested via apt install gcc-14) Ruby: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +YJIT +PRISM [x86_64-linux] Reproduced with both RVM and rbenv (independent installations) 1. Install Ruby 3.4.9 on Ubuntu 26.04. irb works. 2. gem install bundler && bundle install in any project with a non-trivial Gemfile (e.g. Rails 8). Among other things, this installs newer versions of default gems: prism 1.9.0, cgi 0.5.1, date 3.5.1, io-console 0.8.2, etc. 3. Run irb (or any Ruby that loads one of those gems). Segfault or bus error on loading the native .so. The crashing extension varies depending on load order, but I've reproduced it in prism.so, cgi/escape.so, date_core.so, io/console.so, and rbs_extension.so. Removing the newer gem from the gemset (e.g. rm -rf ~/.rvm/gems/ruby-3.4.9/gems/prism-1.9.0) causes Ruby to fall back to the older version that ships with the Ruby tarball (prism 1.5.2), which works — until the next crash on another default gem. Ruby 4.0.3 installed via the same RVM, on the same Ubuntu 26.04 system, runs a non-trivial Rails 8 application with bundle install and bundle exec working without any crashes. This suggests the fix (or whatever change avoids the issue) is on master/4.0 and was not backported to the 3.4 branch. Workarounds attempted (none successful): 1. rvm get stable to install all current Ruby build dependencies (including libncurses5-dev which was initially missing). Ruby itself rebuilt; gems still crash. 2. Rebuilding Ruby with CFLAGS="-fno-ipa-modref" per #21655. RbConfig::CONFIG["CFLAGS"] confirms the flag is in the build. Gems still crash. (Note: I have not verified whether the flag is propagated to the gem build via mkmf.) 3. Rebuilding Ruby with CC=gcc-14 CXX=g++-14 (GCC 14 is available in default 26.04 repositories). Gems still crash. 4. Reinstalling Ruby 3.4.9 via rbenv (independent of RVM) and reproducing from scratch. Same crash. Happy to provide additional information — debug build, full gdb backtrace, build logs, etc. Just let me know what would be most useful. Thank you. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:125441] [Ruby Feature#22060] Improve Pathname by migrating internal methods to pathname.c
by nobu (Nobuyoshi Nakada) 18 May '26

18 May '26

Issue #22060 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22060: Improve Pathname by migrating internal methods to pathname.c https://bugs.ruby-lang.org/issues/22060 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, Pathname implementation is mainly in pathname_builtin.rb and only a few methods in pathname.c. The code in pathname_builtin.rb is using `File` methods probably for platform portabilities. This is kind of smart but is a roundabout way and is hard to understand. I think it can be easier to maintain and more efficient by migrating some internal methods to pathname.c. Comparison with master 9fefb48643: | |master w/o JIT|PR w/o JIT|master w/ JIT|PR w/ JIT| |:-------------------|-------------:|---------:|------------:|--------:| |p1+p2 | 332.541k| 696.202k| 347.315k| 952.254k| | | -| 2.09x| 1.04x| 2.86x| |abs.root? | 3.282M| 97.180M| 3.504M| 82.821M| | | -| 29.61x| 1.07x| 25.23x| |rel.root? | 3.298M| 101.917M| 3.535M| 96.676M| | | -| 30.91x| 1.07x| 29.32x| |abs.absolute? | 22.184M| 110.749M| 31.099M| 129.464M| | | -| 4.99x| 1.40x| 5.84x| |rel.absolute? | 30.862M| 111.914M| 47.010M| 118.712M| | | -| 3.63x| 1.52x| 3.85x| |p1.cleanpath | 395.604k| 904.909k| 418.752k| 1.342M| | | -| 2.29x| 1.06x| 3.39x| |p2.cleanpath | 445.949k| 982.354k| 468.972k| 1.451M| | | -| 2.20x| 1.05x| 3.25x| |relative_path_from | 137.595k| 271.209k| 144.976k| 393.710k| | | -| 1.97x| 1.05x| 2.86x| Although YJIT is not effective on `Pathname#root?`, probably it is too simple for JIT. [GH-16907](https://github.com/ruby/ruby/pull/16907) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125531] [Ruby Feature#18959] Handle gracefully nil kwargs eg. **nil
by Earlopain (Earlopain _) 16 May '26

16 May '26

Issue #18959 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed I believe this can be closed now that https://bugs.ruby-lang.org/issues/20064 was implemented ---------------------------------------- Feature #18959: Handle gracefully nil kwargs eg. **nil https://bugs.ruby-lang.org/issues/18959#change-117354 * Author: LevLukomskyi (Lev Lukomskyi) * Status: Closed ---------------------------------------- The issue: ```ruby def qwe(a: 1) end qwe(**nil) #=> fails with `no implicit conversion of nil into Hash (TypeError)` error { a:1, **nil } #=> fails with `no implicit conversion of nil into Hash (TypeError)` error ``` Reasoning: I found myself that I often want to insert a key/value to hash if a certain condition is met, and it's very convenient to do this inside hash syntax, eg.: ```ruby { some: 'value', **({ id: id } if id.present?), } ``` Such syntax is much more readable than: ```ruby h = { some: 'value' } h[:id] = id if id.present? h ``` Yes, it's possible to write like this: ```ruby { some: 'value', **(id.present? ? { id: id } : {}), } ``` but it adds unnecessary boilerplate noise. I enjoy writing something like this in ruby on rails: ```ruby content_tag :div, class: [*('is-hero' if hero), *('is-search-page' if search_page)].presence ``` If no conditions are met then the array is empty, then converted to nil by `presence`, and `class` attribute is not rendered if it's nil. It's short and so convenient! There should be a similar way for hashes! I found this issue here: https://bugs.ruby-lang.org/issues/8507 where "consistency" thing is discussed. While consistency is the right thing to do, I think the main point here is to have fun with programming, and being able to write stuff in a concise and readable way. Please, add this small feature to the language, that'd be so wonderful! 🙏 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125511] [Ruby Bug#22071] super in method in module that is refined results in NoMethodError
by jeremyevans0 (Jeremy Evans) 16 May '26

16 May '26

Issue #22071 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22071: super in method in module that is refined results in NoMethodError https://bugs.ruby-lang.org/issues/22071 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.9] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We currently support refinements of modules, even though doc/syntax/refinements.rdoc and https://github.com/ruby/ruby/wiki/Refinements-Spec imply that we would not respect refinements of included or prepended modules and would only respect refinements of classes and superclasses. If you refine a module, and have the refined method definition call `super` and the method in the refined module call `super`, and that refined method is found first during method lookup, the `super` call in the method in the refined module results in a `NoMethodError`. Example: ```ruby module F def a; "F" + super end end class A def a; "A" end end class B < A include F end p B.new.a module R refine F do def a; "R" + super end end end using R p B.new.a ``` Output: ``` "FA" t.rb:2:in 'F#a': super: no superclass method 'a' for an instance of B (NoMethodError) from t.rb:17:in 'a' from t.rb:22:in '<main>' ``` Two things to note: * Before the refinement is activated, things work as expected, returning "FA". * After the refinement is activated, the `NoMethodError` is raised not in the refinement method `super` (line 17), but in the `super` in the method in the module that is refined (line 2). What should be the expected behavior here? I can think of two possibilities: * Per the documentation, we should not consider refinements of included/prepended modules. So in this example, we should print "FA" and ignore the refinement instead of raising the `NoMethodError`. In this case, it would be best to raise during the `refine F` call, and prohibit the refining of modules completely. This would break backwards compatibility, though I'm not sure how much real world code uses refinements of modules. * Fix `super` when the refinement is activated to use the correct method lookup and return "RFA" instead of raising the `NoMethodError`. Also fix the documentation to describe how refinements of included/prepended modules work during method lookup. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124286] [Ruby Bug#21789] `IO#flush` doesn't invoke fiber scheduler io_write hook
by noteflakes (Sharon Rosner) 16 May '26

16 May '26

Issue #21789 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #21789: `IO#flush` doesn't invoke fiber scheduler io_write hook https://bugs.ruby-lang.org/issues/21789 * Author: noteflakes (Sharon Rosner) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When calling `IO#flush` or closing an IO with unflushed writes, the flushing is done by calling `rb_io_blocking_region_wait` and eventually doing a `write` system call. When done in a non-blocking fiber with an active fiber scheduler, this will invoke the `#blocking_operation_wait` fiber scheduler hook, which will run the system call in a worker thread, and therefore the flushing bypasses the async I/O capabilities of the fiber scheduler. The proposed fix is to test for the presence of a fiber scheduler in `io_flush_buffer_async` and invoke the `#io_write` fiber scheduler hook with the unflushed part of the IO's write buffer. Associated PR here: https://github.com/ruby/ruby/pull/15609 -- https://bugs.ruby-lang.org/

2 1