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

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

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

[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

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

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

16 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

[ruby-core:125491] [Ruby Feature#22068] Adding post-quantum cryptography (PQC) support across Ruby standard libraries
by jaruga (Jun Aruga) 15 May '26

15 May '26

Issue #22068 has been reported by jaruga (Jun Aruga). ---------------------------------------- Feature #22068: Adding post-quantum cryptography (PQC) support across Ruby standard libraries https://bugs.ruby-lang.org/issues/22068 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Summary and motivation Post-quantum cryptography (PQC) means cryptography algorithm which people can safely use after (post) quantum computing is practically used in the future. By using the quantum computing which is much more powerful than the current computing, it can be possible to crack the current non-PQC algorithms. The goal of this ticket is to make Ruby (including libraries: default gems + bundle gems) work in the environment where only post-quantum cryptography (PQC)-supported algorithms are enabled, and other cryptography algorithms such as RSA are disabled. PQC-supported algorithms are only ML-DSA, ML-KEM and SLH-DSA for now. ML-DSA is used for signature (certification), and ML-KEM is used for connection. As I heard from my colleagues working for OpenSSL, that SLH-DSA is not ready to be used, we can ignore SLH-DSA for now. Ruby OpenSSL (ruby/openssl) already supports PQC by the ticket [ruby/openssl#894][ruby-openssl-pqc-issue]. And there are some works are needed for other standard libraries using Ruby OpenSSL in Ruby to support PQC. I cite the following text from the [NIST][nist-wikipedia]'s [PQC document][nist-pqc]. NIST is an organization deciding cryptography specifications in my understanding. > Some engineers even predict that within the next twenty or so years sufficiently large quantum computers will be built to break essentially all public key schemes currently in use. Historically, it has taken almost two decades to deploy our modern public key cryptography infrastructure. Therefore, regardless of whether we can estimate the exact time of the arrival of the quantum computing era, we must begin now to prepare our information security systems to be able to resist quantum computing. I also cite the following text from DigiCert, a security company's blog. ([link][digicert-blog-google-mtc]) > Gartner predicts that by 2029, conventional asymmetric cryptography like RSA and ECC will be unsafe for protecting sensitive data due to “harvest-now, decrypt-later" threats—even before a quantum break occurs. So, it's better to prepare PQC support now. As an example of the actual movement European Commission is trying to migrate from non-PQC to PQC.([link][ec-pqc]) ## Proof of concept I manage my proof-of-concept scripts on my [junaruga/ruby-pqc-test] repository. For now, there are only some scripts to test RubyGems and Bundler in PQC use cases. ## Tasks I checked ruby/ruby including default gems and bundled gems at the master branch commit `93f1010f70a3ac924c3b37e4ae82cf1a669fcbf0` which was the latest at that time. While ruby/ruby original code doesn't have PQC logic, the following libraries that have the own upstream project need to be modified to support PQC use cases in my investigation. And I am motivated to work on these tasks, adding the PQC features and/or tests. I will open the issue ticket for each upstream project ruby/* one by one. * [ruby/rubygems](https://github.com/ruby/rubygems) - Add PQC features * [ruby/rubygems bundler](https://github.com/ruby/rubygems/tree/master/bundler) - Add PQC features * [ruby/net-http](https://github.com/ruby/net-http) - default gem - Update code comments and add PQC tests * [ruby/open-uri](https://github.com/ruby/open-uri) - default gem - Add PQC tests * [ruby/spec](https://github.com/ruby/spec) - spec/ - Add PQC tests * [ruby/drb](https://github.com/ruby/drb): bundled gem - Add PQC features * [ruby/rbs](https://github.com/ruby/rbs): bundled gem - Not sure. There is `stdlib/openssl/0/openssl.rbs`. Note I used the following [ripgrep]'s `rg` command (an enhanced `grep` command) to check the affected files by PQC. ``` $ rg "require +['\"]openssl['\"]|OpenSSL" --type ruby ``` Please let me know what you think. [openssl-35-release]: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/ [ruby-openssl-pqc-issue]: https://github.com/ruby/openssl/issues/894 [nist-wikipedia]: https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology [nist-pqc]: https://csrc.nist.gov/projects/post-quantum-cryptography [ec-pqc]: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation… [digicert-blog-google-mtc]: https://www.digicert.com/blog/google-merkle-tree-certificates [junaruga/ruby-pqc-test]: https://github.com/junaruga/ruby-pqc-test [ripgrep]: https://github.com/BurntSushi/ripgrep -- https://bugs.ruby-lang.org/

2 3