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

[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:124594] [Ruby Bug#21844] Inconsistent ArgumentError message for Data::define.new
by jnchito (Junichi Ito) 18 May '26

18 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 13

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

17 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:125518] [Ruby Bug#22072] [BUG] should have cvar cache entry
by rmosolgo (Robert Mosolgo) 16 May '26

16 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/

2 1

[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:125428] [Ruby Bug#22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope
by jeremyevans0 (Jeremy Evans) 16 May '26

16 May '26

Issue #22058 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22058: {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope https://bugs.ruby-lang.org/issues/22058 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found that Method#super_method and InstanceMethod#super_method do not work correctly in some cases for refined methods. At the least, there is a definite bug, which is that #super_method inside a scope with a refinement activated for the method results in a loop over the refined methods. I'm not sure if the semantics for #super_method for refined methods were ever discussed. Other than the bug regarding the loop over the refinement, the currently semantics seem to be: * While handling additional refined methods for the same class as the current method, #super_method will consider the refinements active at the point the method was created * For ancestors, #super_method will consider the refinements active in the scope calling #super_method These semantics seem questionable. My guess is they are not the result of intentional design, but due purely to implementation details. I see two possibilities: 1. Keep the current behavior, where results depend on refinements activated in the caller's namespace. In this case, I recommend that we not have different handling when there are other refinements for the same class as the current method should. If refinements are not in scope, #super_method should not return them. We should also consider whether #super_method should error if the receiver is a refinement method for a refinement not activated in the caller's scope. 2. Change #super_method so that it depends on the refinements activated in the namespace it was created in, for ancestors as well as for the current class. This would make #super_method return the same result no matter where it was called. I think option 2 makes more sense, but it requires that Method/InstanceMethod objects for refined methods keep a reference to the scope in which they were created. A related minor bug I found during this research is the #inspect output for #super_method results for refined methods also does not use the same format, indicating there is something internally different. Here's example code showing these issues, with commented output below: ```ruby class B def b = 16 end class A < B def b = 8 + super end module M1 refine(A){def b = 1 + super} end module M2 refine(A){def b = 2 + super} end module M3 refine(A){def b = 4 + super} end module M4 refine(B){def b = 4 + super} end I = A.new.method(:b) C = A.instance_method(:b) module N0 using M1 using M3 I = A.new.method(:b) C = A.instance_method(:b) end module N using M1 using M2 using M3 using M4 I = A.new.method(:b) C = A.instance_method(:b) puts "", "Inside module using all refinements using method created using all refinements:" p I i = I 6.times do i = i.super_method p i end puts p C c = C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using some refinements:" p N0::I i = N0::I 6.times do i = i.super_method p i end puts p N0::C c = N0::C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using no refinements:" p ::I i = ::I 6.times do break unless i = i.super_method p i end puts p ::C c = ::C 6.times do break unless c = c.super_method p c end end module N0 using M1 using M3 puts "", "Inside module using some refinements using method created using all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end end puts "", "Top level using method created with all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with some refinements:" p N0::I i = N0::I 6.times do break unless i = i.super_method p i end puts p N0::C c = N0::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with no refinements:" p I i = I 6.times do break unless i = i.super_method p i end puts p C c = C 6.times do break unless c = c.super_method p c end ``` First, the bug. This shows a loop among active refinements. After going through M3, M2, and M1, it loops back to M3. This also shows weird #inspect output, with #super_method not showing the main class. ``` Inside module using all refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> ``` This shows the dynamic scoping of the #super_method. At time of call, only M3 and M1 are in scope. You see in the first loop, only M3 and M1 are used, but subsequent loops use M3, M2, and M1. ``` Inside module using all refinements using method created using some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> ``` This shows a case where the Method was created with no refinements activated. Refinements for superclasses that are active in the current scope are still picked up: ``` Inside module using all refinements using method created using no refinements: #<Method: A#b() t/t43.rb:30> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> ``` More evidence for dynamic scoping. This is the opposite of the second example, where the first loop has M3, M2, and M1, and subsequent loops have M3 and M1. ``` Inside module using some refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> ``` This shows the behavior when no refinements are activated in the current scope. It still includes refinements for the same class as the current method, but no refinements for superclasses. Also, note that there is no longer a loop, because there are no refinements activated: ``` Top level using method created with all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This shows that only the refinements were activated at the point the method was created are included. ``` Top level using method created with some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This output doesn't show any problems, it shows that if refinements were not activated when the method was created, and are not activated when #super_method is called, that #super_method ignores refinements, which is what you would expect. ``` Top level using method created with no refinements: #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` -- https://bugs.ruby-lang.org/

4 11

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

15 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

[ruby-core:125497] [Ruby Bug#22070] `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc
by AMomchilov (Alexander Momchilov) 15 May '26

15 May '26

Issue #22070 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Bug #22070: `Thread.each_caller_location(1, 1)` segfaults when called from a cfunc https://bugs.ruby-lang.org/issues/22070 * Author: AMomchilov (Alexander Momchilov) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading the `label` of a `Thread::Backtrace::Location` (directly or indirectly via e.g. `to_s`) segfauls if called from within `Thread.each_caller_location(1, 1) { it.label }`. Reading the `lineno` or `path` seems to not cause any problems, perhaps by coincidence. ## Minimal repro ```sh ruby -e 'tap { Thread.each_caller_location(1, 1) { it.label } }' # 🧨 Boom ``` ## More cases <details><summary><code>repro.rb</code></summary> ```ruby # All four conditions must hold; varying any one makes the crash go away: # # 1. The yielded location is inspected via a `cme`-reading method # (`label`, `base_label`, `to_s`, `inspect`). # * The `iseq`-based methods (`path`, `absolute_path`, `lineno`) seem to survive by accident. # 2. `start` is exactly 1. # 3. `length` is exactly 1. # * Ranges that compute to length=1 (`1..1`, `1...2`) crash # * e.g. `1..3` (length=3) does not. # 4. The caller is inside a C-method frame (`tap`, `Array#each`, `instance_exec`, `eval`, ...). # * Top-level and plain Ruby methods are safe. $ruby = begin require "rbconfig" RbConfig.ruby rescue LoadError ENV["_"] || "ruby" end def check(label, code) out = IO.popen([$ruby, "-e", code, err: [:child, :out]], &:read) crashed = !$?.success? || out.include?("[BUG]") printf " %-7s %s\n", (crashed ? "CRASH" : "OK"), label end puts "== Which Location method is accessed (start=1, length=1, from tap{}) ==" check("it.path", "tap { Thread.each_caller_location(1, 1) { it.path } }") check("it.absolute_path", "tap { Thread.each_caller_location(1, 1) { it.absolute_path } }") check("it.lineno", "tap { Thread.each_caller_location(1, 1) { it.lineno } }") check("it.label", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("it.base_label", "tap { Thread.each_caller_location(1, 1) { it.base_label } }") check("it.to_s", "tap { Thread.each_caller_location(1, 1) { it.to_s } }") check("it.inspect", "tap { Thread.each_caller_location(1, 1) { it.inspect } }") puts "== Vary `start` (length=1, .label, from tap{}) ==" check("start=0", "tap { Thread.each_caller_location(0, 1) { it.label } }") check("start=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("start=2", "tap { Thread.each_caller_location(2, 1) { it.label } }") check("start=3", "tap { Thread.each_caller_location(3, 1) { it.label } }") puts "== Vary `length` (start=1, .label, from tap{}) ==" check("length=1", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("length=2", "tap { Thread.each_caller_location(1, 2) { it.label } }") check("length=3", "tap { Thread.each_caller_location(1, 3) { it.label } }") check("length=4", "tap { Thread.each_caller_location(1, 4) { it.label } }") puts "== Range forms equivalent to (start=1, length=1) ==" check("(1, 1)", "tap { Thread.each_caller_location(1, 1) { it.label } }") check("(1..1)", "tap { Thread.each_caller_location(1..1) { it.label } }") check("(1...2)", "tap { Thread.each_caller_location(1...2) { it.label } }") check("(1..2)", "tap { Thread.each_caller_location(1..2) { it.label } }") puts "== Caller context (start=1, length=1, .label) ==" check("top-level", 'Thread.each_caller_location(1, 1) { it.label }') check("tap { ... }", 'tap { Thread.each_caller_location(1, 1) { it.label } }') check("[1].each { ... }", '[1].each { Thread.each_caller_location(1, 1) { it.label } }') check("instance_exec", 'instance_exec { Thread.each_caller_location(1, 1) { it.label } }') check("eval '...'", %{eval 'Thread.each_caller_location(1, 1) { it.label }'}) check("def m; ...; end; m", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; m') check("tap { m }", 'def m; Thread.each_caller_location(1, 1) { it.label }; end; tap { m }') puts puts "Ruby: #{RUBY_DESCRIPTION}" ``` </details> -- https://bugs.ruby-lang.org/

5 6

[ruby-core:125492] [Ruby Bug#22069] Backport openssl 3.2.4/3.3.3/4.0.2
by rhenium (Kazuki Yamaguchi) 15 May '26

15 May '26

Issue #22069 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22069: Backport openssl 3.2.4/3.3.3/4.0.2 https://bugs.ruby-lang.org/issues/22069 * Author: rhenium (Kazuki Yamaguchi) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The main change is OpenSSL 4.0 support. OpenSSL 4.0 was released on 2026-04-14 with several incompatible changes, and the default gems currently included in Ruby 3.3.11/3.4.9/4.0.4 do not compile against it. Although this can be considered more of a feature rather than a bug fix, I believe this would still be useful to backport. Branch maintainers, what do you think? I've created GitHub PRs for each stable branch: - ruby_3_3 (v3.2.2 -> v3.2.4) https://github.com/ruby/ruby/pull/16945 - ruby_3_4 (v3.3.1 -> v3.3.3) https://github.com/ruby/ruby/pull/16946 - ruby_4_0 (v4.0.0 -> v4.0.2) https://github.com/ruby/ruby/pull/16947 -- https://bugs.ruby-lang.org/

5 4