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

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

10 Aug '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 5

[ruby-core:126360] [Ruby Bug#22239] Multiple buffer clear errors in IO
by YO4 (Yoshinao Muramatsu) 10 Aug '26

10 Aug '26

Issue #22239 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22239: Multiple buffer clear errors in IO https://bugs.ruby-lang.org/issues/22239 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While testing my changes on the Windows platform to use an encoding converter for newline conversion for "r", I discovered a failure in test_reopen. This corresponds to case (3) below. I asked an LLM to investigate similar cases and related code that raised concerns, and was able to identify several issues, so I am reporting them here. I'll submit a PR later. I used Hy3 (High) via opencode GO to perform this survey and create the test code. (For transparency—this is not an advertisement.) case(1) In io.c, free_io_buffer only clears ptr and left off, len and capa as they were. Since clear_readconv releases the character buffer through it, READ_CHAR_PENDING() kept reporting pending characters after the buffer had been released. As a result, every operation that clears the code converter (IO#rewind, IO#seek, IO#pos=, IO#flush, IO#binmode, IO#tell, IO#set_encoding, ...) left the IO in a state where byte oriented reads raise IOError. Also IO#eof? answers false at the end of file and IO#sysseek refuses to work. ``` File.binwrite("t", "foo") open("t", "rt") do |f| f.ungetc(f.getc) f.rewind f.getbyte # => 'IO#getbyte': byte oriented read for character buffered IO (IOError) end ``` case(2) IO#reopen(io) only flushes the write buffer when the IO is writable, and never unreads the read buffer. The buffer happens to be dropped by the io_seek after dup2, but only when the other stream is readable and seekable, so a read-write IO keeps stale bytes otherwise. ``` File.binwrite("t", "0123456789") f = File.open("t", "r+b") f.getbyte IO.pipe do |r, w| w.write("ABC"); w.close f.reopen(r) f.read # => "123456789ABC" instead of "ABC" end ``` case(3) IO#reopen(name) discards the byte buffer but keeps the code converter and the character buffer, so characters left over from the previous stream leak into the reopened one. ``` File.binwrite("t", "foo") open(File::NULL, "rt") do |f| f.ungetc("a") f.reopen("t") f.read # => "afoo" instead of "foo" end ``` case(4) IO#reopen(io) relies on flush_before_seek to drop the buffers, but io_unread returns at once when rbuf is empty and therefore never reaches clear_codeconv. With characters pending in cbuf and nothing in rbuf they leak into the reopened stream. ``` File.write("t", "foo\n") open(File::NULL, "rt") do |f| f.ungetc("a") open("t", "rt") {|f2| f.reopen(f2)} f.gets # => "afoo\n" instead of "foo\n" end ``` case(5) Unlike IO#rewind, IO#seek and IO#pos= do not clear the character buffer. As io_unread returns at once when rbuf is empty, an ungotten character survives the repositioning while it does not in binary mode. ``` File.write("t", "foo\n") open("t", "rt") do |f| f.ungetc("a") f.seek(2, :SET) f.getc # => "a" instead of "o" end ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125818] [Ruby Bug#22126] Stack underflow for partial DCE and loops
by viralpraxis (Iaroslav Kurbatov) 10 Aug '26

10 Aug '26

Issue #22126 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22126: Stack underflow for partial DCE and loops https://bugs.ruby-lang.org/issues/22126 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T13:29:36Z master 13fe77dd2b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ruby ruby --parser prism -e 'if []; else; a => [*, 42, *]; end' -- raw disasm-------- trace: 1 0000 putnil ( 1) 0001 leave ( 1) <L018> [sp: 1, unremovable: 0, refcnt: 1] 0002 dup ( 1) 0003 topn 2 ( 1) 0005 opt_le <calldata:<=, 1> ( 1) 0007 branchunless <L021> ( 1) 0009 topn 3 ( 1) 0011 topn 1 ( 1) 0013 opt_aref <calldata:[], 1> ( 1) 0015 putobject 42 ( 1) 0017 dupn 2 ( 1) 0019 checkmatch 2 ( 1) 0021 dup ( 1) 0022 branchif <L023> ( 1) 0024 putspecialobject 1 ( 1) 0026 putobject "%p === %p does not return true" ( 1) 0028 topn 3 ( 1) 0030 topn 5 ( 1) 0032 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0034 setn 10 ( 1) 0036 putobject false ( 1) 0038 setn 12 ( 1) 0040 pop ( 1) 0041 pop ( 1) <L023> [sp: 4, unremovable: 0, refcnt: 1] 0042 setn 2 ( 1) 0044 pop ( 1) 0045 pop ( 1) 0046 branchif <L020> ( 1) 0048 putobject_INT2FIX_1_ ( 1) 0049 opt_plus <calldata:+, 1> ( 1) 0051 jump <L018> ( 1) <L021> [sp: 1, unremovable: 0, refcnt: 1] * 0053 adjuststack 3 ( 1) 0055 putspecialobject 1 ( 1) 0057 putobject "%p does not match to find pattern" ( 1) 0059 topn 2 ( 1) 0061 opt_send_without_block <calldata:core#sprintf, 2> ( 1) 0063 setn 4 ( 1) 0065 putobject false ( 1) 0067 setn 6 ( 1) 0069 pop ( 1) 0070 pop ( 1) 0071 jump <L012> ( 1) <L020> [sp: 1, unremovable: 0, refcnt: 1] 0073 adjuststack 3 ( 1) 0075 pop ( 1) 0076 jump <L003> ( 1) <L012> [sp: -1, unremovable: 0, refcnt: 1] 0078 pop ( 1) 0079 putspecialobject 1 ( 1) 0081 topn 4 ( 1) 0083 branchif <L024> ( 1) 0085 putobject NoMatchingPatternError ( 1) 0087 putspecialobject 1 ( 1) 0089 putobject "%p: %s" ( 1) 0091 topn 4 ( 1) 0093 topn 7 ( 1) 0095 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0097 opt_send_without_block <calldata:core#raise, 2> ( 1) 0099 jump <L025> ( 1) <L024> [sp: -1, unremovable: 0, refcnt: 1] 0101 putobject NoMatchingPatternKeyError ( 1) 0103 putspecialobject 1 ( 1) 0105 putobject "%p: %s" ( 1) 0107 topn 4 ( 1) 0109 topn 7 ( 1) 0111 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0113 topn 7 ( 1) 0115 topn 9 ( 1) 0117 opt_send_without_block <calldata:new, 3> ( 1) 0119 opt_send_without_block <calldata:core#raise, 1> ( 1) <L025> [sp: -1, unremovable: 0, refcnt: 1] 0121 adjuststack 7 ( 1) 0123 putnil ( 1) 0124 leave ( 1) <L003> [sp: -1, unremovable: 0, refcnt: 1] 0125 adjuststack 6 ( 1) 0127 putnil ( 1) 0128 leave ( 1) --------------------- -e:1: argument stack underflow (-2) -e: compile error (SyntaxError) ``` proposed patch: https://github.com/ruby/ruby/pull/17449 every version since 3.4.0-preview2 is affected -- https://bugs.ruby-lang.org/

5 5

[ruby-core:126235] [Ruby Feature#22226] Ractor: class/module ownership -- restrict modification to the Ractor that created it
by ko1 (Koichi Sasada) 10 Aug '26

10 Aug '26

Issue #22226 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22226: Ractor: class/module ownership -- restrict modification to the Ractor that created it https://bugs.ruby-lang.org/issues/22226 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 4.1 ---------------------------------------- ## Abstract Every class/module records the Ractor that created it as its *owner*. Only the owner Ractor can modify it. Reading is unchanged and allowed from any Ractor. This replaces several ad-hoc "main Ractor only" rules with a single rule keyed on the creator. It **relaxes** the rules for classes a Ractor creates itself, and **tightens** them for classes created by somebody else. No Ruby-level API is added: ownership is recorded internally and is not exposed. --- ## 1. Motivation ### 1.1 The current rules ask the wrong question Today's restrictions ask *"are you the main Ractor?"*. They never ask *"did you create this class?"*. The result is inconsistent in both directions. A non-main Ractor may freely redefine **any** class in the process: ```ruby class C; end Ractor.new { C.define_method(:m) { 1 }; :done }.value #=> :done (works today) Ractor.new { class String; def foo = 1; end; :done }.value #=> :done (works today) Ractor.new { def f = 42; f() }.value #=> 42 (works today; defines Object#f) Ractor.new { Object.send(:remove_const, :FOO); :done }.value #=> :done (works today) ``` ...but it may **not** set an instance variable on a class it created itself: ```ruby Ractor.new { k = Class.new # nobody else can even name this class yet k.instance_variable_set(:@iv, 1) }.value #=> Ractor::IsolationError: # can not set instance variables of classes/modules by non-main Ractors ``` ...nor give it an unshareable constant: ```ruby Ractor.new { k = Class.new k.const_set(:X, "str".dup) }.value #=> Ractor::IsolationError: # can not set constants with non-shareable objects by non-main Ractors ``` The first group is unrestricted although it affects the whole process. The second group is forbidden although it affects nothing but the Ractor doing it. The rules are exactly inverted with respect to who is actually affected. ### 1.2 A Ractor's classes can be redefined under it by another Ractor Because any Ractor may modify any class, the code a Ractor runs can be changed by somebody else at any moment: ```ruby Ractor.new { class String; def upcase = :patched; end; :done }.value "abc".upcase #=> :patched # evaluated in the *main* Ractor ``` ```ruby FOO = 1 Ractor.new { Object.send(:remove_const, :FOO); :removed }.value FOO #=> NameError: uninitialized constant FOO ``` Both of these run fine today. There is no way for a Ractor to rely on the classes it uses. ### 1.3 Class internals have no single writer `m_tbl`, `const_tbl` and the class fields can be written by any Ractor today. This means the implementation cannot assume a single writer for any class, which stands in the way of synchronization and caching work (and it is also how the `cvar_overtaken()` bug below arose: a *read* path physically deletes a table entry, potentially of another Ractor's class). --- ## 2. Proposal A class/module records its creator Ractor as its **owner**. Only the owner may: * define/remove/undef methods, `alias`, change method visibility * `include`/`prepend` into it, and `Module#refine` targeting it * define/remove constants, register `autoload` * set instance variables on the class/module object Non-owner Ractors get `Ractor::IsolationError`. **Reading is completely unchanged**: method calls, instantiation, subclassing, constant reads and instance-variable reads all work from any Ractor as before. In exchange, the previous "main Ractor only" rules for class instance variables and unshareable constant values become "**owner Ractor only**". A Ractor gets full use of the classes it creates. Since all classes/modules created at boot or by main-Ractor code (including everything loaded by `require`) are owned by the main Ractor, this is equivalent to today's rules for programs that do not create classes inside non-main Ractors. --- ## 3. Examples ### 3.1 Newly allowed: a Ractor can fully use the classes it creates Instance variables on a class the Ractor created: ```ruby Ractor.new { k = Class.new k.instance_variable_set(:@iv, 1) # was: IsolationError, even for a shareable value! k.instance_variable_set(:@iv, "str".dup) # was: IsolationError k.instance_variable_get(:@iv) #=> "str" }.value ``` **Unshareable values in constants** of a class the Ractor created. This was the main Ractor's privilege before; now every Ractor has it for its own classes: ```ruby Ractor.new { k = Class.new k::BUF = "buffer".dup # unshareable value; was: IsolationError k::BUF << "!" # ...and the owner can freely use it k::BUF #=> "buffer!" }.value Ractor.new { k = Class.new k.const_set(:LIST, [1, 2, 3]) # an unfrozen Array is unshareable too k::LIST << 4 k::LIST #=> [1, 2, 3, 4] }.value ``` The value stays private to the owner -- reading it from another Ractor raises, which is exactly the rule that applied to the main Ractor before: ```ruby port = Ractor::Port.new r = Ractor.new(port) { |pt| k = Class.new; k::BUF = "buffer".dup; pt << k; Ractor.receive } k = port.receive k::BUF #=> Ractor::IsolationError: can not access non-shareable objects in constant # #<Class:0x...>::BUF of a class/module created by another Ractor. ``` A *shareable* value in the same position is readable from anywhere, as before: ```ruby r = Ractor.new(port) { |pt| k = Class.new; k::N = 42; pt << k; Ractor.receive } k = port.receive k::N #=> 42 ``` Classes defined under a module the Ractor created itself work fully: ```ruby Ractor.new { mod = Module.new mod.const_set(:Foo, Class.new { def m = :ok }) mod::Foo.new.m #=> :ok }.value ``` ### 3.2 Newly prohibited: modifying a class created by another Ractor ```ruby class C; end module M; end Ractor.new { def f = 42 }.value #=> can not modify Object because it is created by another Ractor # (top-level `def` defines a private method on Object) Ractor.new { class String; def foo = 1; end }.value #=> can not modify String because it is created by another Ractor Ractor.new { C.define_method(:m) { 1 } }.value Ractor.new { C.send(:alias_method, :a, :inspect) }.value Ractor.new { C.send(:private, :inspect) }.value Ractor.new { C.send(:undef_method, :inspect) }.value Ractor.new { C.include(M) }.value Ractor.new { C.prepend(M) }.value Ractor.new { Module.new { refine(C) { def z = 1 } } }.value Ractor.new { C.autoload(:Zz, "zz") }.value #=> can not modify C because it is created by another Ractor Ractor.new { C.const_set(:X, 1) }.value # note: even a *shareable* value now raises #=> can not set constants of classes/modules created by another Ractor Ractor.new { class TopCls; end }.value # a top-level class name... Ractor.new { module TopMod; end }.value # ...and a top-level module name #=> can not set constants of classes/modules created by another Ractor # (both write a constant into Object) Ractor.new { Object.send(:remove_const, :FOO) }.value #=> can not modify Object because it is created by another Ractor Ractor.new { C.instance_variable_set(:@iv, 1) }.value #=> can not set instance variables of classes/modules created by another Ractor ``` Patterns that stop working: ```ruby # a registry in Class#inherited that writes into the superclass Base = Class.new { def self.inherited(sub) = const_set(:"Sub#{sub.object_id}", sub) } Ractor.new { Class.new(Base) }.value #=> can not set constants of classes/modules created by another Ractor # lazy definition on first touch M2 = Module.new { def self.const_missing(n) = const_set(n, Class.new) } Ractor.new { M2::Foo }.value #=> can not set constants of classes/modules created by another Ractor ``` Both work if the definition happens before the Ractor is spawned (eager loading). ### 3.3 Unchanged ```ruby Ractor.new { "abc".upcase }.value #=> "ABC" Ractor.new { C.new }.value # instantiation Ractor.new { Class.new(String) { def m = :ok }.new.m }.value #=> :ok (subclassing is creation) Ractor.new { require "time"; Time.now.respond_to?(:xmlschema) }.value #=> true ``` `require` from a non-main Ractor keeps working because `Ractor#require` performs the load on the main Ractor, so the library's classes are defined by (and owned by) the main Ractor. `def` on an object a Ractor created is also unaffected -- an ordinary object's singleton class is created by, and owned by, the Ractor that triggers it: ```ruby Ractor.new { o = Object.new; def o.f = :ok; o.f }.value #=> :ok ``` ### 3.4 Summary table | operation from a non-main Ractor | today | proposal | |---|---|---| | define a method on a foreign class | OK | **IsolationError** | | top-level `def` | OK | **IsolationError** | | `include`/`prepend`/`refine` a foreign class | OK | **IsolationError** | | set a **shareable** constant on a foreign class | OK | **IsolationError** | | set an **unshareable** constant on a foreign class | IsolationError | IsolationError | | `remove_const` / `autoload` on a foreign class | OK | **IsolationError** | | set an ivar on a foreign class | IsolationError | IsolationError | | define a method on its **own** class | OK | OK | | set a **shareable** constant on its **own** class | OK | OK | | set an **unshareable** constant on its **own** class | IsolationError | **OK** | | set an ivar on its **own** class | IsolationError | **OK** | | read / call / instantiate / subclass any class | OK | OK | --- ## 4. How the proposal answers the motivation * **1.1 (rules ask the wrong question)** -- the rules now ask "did you create this?" instead of "are you main?". Every restriction is on the class of somebody else, and every relaxation is on your own class. The two inverted cases in 1.1 both flip to the right side. The old "main Ractor only" rules become the special case *"boot-time classes are owned by the main Ractor"*, so they are no longer separate rules. * **1.2 (classes changed under you)** -- no Ractor can modify a class it did not create, so the classes a Ractor uses cannot be redefined by another Ractor. * **1.3 (no single writer)** -- every class/module now has exactly one Ractor which can write its method table, constant table and fields. --- ## 5. What this does **not** give Ownership bounds *who may write*, not *what readers may see*. Reads stay unsynchronized and a class modification is not atomic, so a non-owner Ractor can still observe a class in the middle of being modified by its owner: after the first `def` of a `class ... end` body but before the second, or while `include`/`prepend` is rewiring the ancestor chain. The guarantee is **a single writer per class/module**, not a consistent view for readers. This proposal is not, and does not claim to be, full isolation of class state. --- ## 6. Details * **Singleton classes / metaclasses** are owned by the owner of the object they are attached to, not by the Ractor that happened to trigger their lazy creation. `def C.foo` is allowed exactly for the owner of `C`: ```ruby class C; end Ractor.new { C.singleton_class; :touched }.value # another Ractor touches it first class << C; def foo = :ok; end # still fine in main C.foo #=> :ok Ractor.new { class << C; def bar = 1; end }.value #=> IsolationError ``` * **Terminated owner**: a class whose owner Ractor has finished becomes permanently read-only for everybody, including the main Ractor. ```ruby K = Ractor.new { Class.new { def x = :made_in_ractor } }.value K.new.x #=> :made_in_ractor (reading is fine) K.define_method(:y) { 1 } #=> IsolationError (nobody owns it any more) ``` There is intentionally no API to look up or transfer ownership. * **Class variables** are *not* covered by the relaxation. They are shared across the whole inheritance chain and the class they are physically stored in can migrate over time (`cvar_overtaken`), so no single owner can be defined for them. Writes still require the main Ractor, and additionally must not cross the ownership boundary (the class actually written into must be owned), so class fields keep a single writer. * **Copying a foreign class**: `Class#dup`/`clone` of a class created by another Ractor produces a copy owned by the copying Ractor. It raises if the source's constants or instance variables refer to unshareable objects (they would leak across Ractors); copying classes holding only shareable values works. This gives a mutation-free alternative to monkey-patching: ```ruby S = Class.new; S.const_set(:OK, 1) Ractor.new { k = S.dup; k.define_method(:m) { 1 }; k.new.m }.value #=> 1 ``` * **Top-level class and module names**: `class Foo; end` / `module Foo; end` at the top level of a non-main Ractor writes a constant into `Object`, so both are prohibited. Define them under a module the Ractor creates itself instead (`mod = Module.new; mod.const_set(:Foo, Class.new)`). Integration with `Ruby::Box` is future work. * **Bug fix included**: `cvar_overtaken()` physically deleted a duplicated cvar entry from the `front` class, and that path is reachable from *read* operations (`rb_cvar_find`) -- i.e. a cross-Ractor write triggered by a read. The clean-up is now skipped unless the current Ractor owns `front`. --- ## 7. Incompatibility Only code that modifies classes from a non-main Ractor is affected. Concretely, the following raise `Ractor::IsolationError` where they used to work: * method definition / `alias` / visibility change on a foreign class, including top-level `def` * `include`/`prepend` into a foreign class, `refine` targeting one * setting a **shareable** constant on a foreign class, `remove_const`, `autoload` registration * `Class#inherited` and `const_missing`/`method_missing` hooks which mutate a foreign class Migration is usually "define it before spawning the Ractor" (eager loading), or "create the class inside the Ractor that uses it", or "`dup` the foreign class and modify the copy". Programs which never define classes inside non-main Ractors are unaffected. --- ## 8. Open questions / future work * `freeze` of a foreign class is still allowed. It is a behavior-changing write and should probably be owner-only too. * `Module#set_temporary_name` is not checked yet. * Singleton class ownership is not transferred by `Ractor#send(move: true)`. * Integration with `Ruby::Box`, so that non-main Ractors can define top-level class/module names. * Should the error message for a class owned by the main Ractor say "owned by the main Ractor" rather than "created by another Ractor"? The current wording is confusing for top-level `def`, where the user never mentioned `Object`. --- ## 9. Implementation https://github.com/ruby/ruby/pull/17913 The owner is stored in `rb_classext_t::owner_ractor` as the Ractor object; `0` means the main Ractor, so single-Ractor programs get no additional GC edges. It is marked from the classext and updated on compaction, so the comparison never sees a dangling or reused reference. Method-table checks funnel through `rb_class_modify_check()`; constant/ivar/cvar checks replace the previous `rb_ractor_main_p()` checks in `variable.c`. The class-ivar fast paths in `vm_insnhelper.c` switch from "main Ractor" to "owner Ractor", which keeps them valid because the owner is the only writer and its threads are serialized by the per-Ractor lock. `make btest` (2053 tests), `make test-all` (35797 tests, 0 failures / 0 errors) and `make test-spec` (32628 examples, 0 failures / 0 errors / 0 tagged) all pass. Three tests which relied on cross-Ractor method definition were rewritten so that the owner Ractor performs the definition. ## Notes * Above description is written by Claude code from my explanation. * The biggest motivation is "main-Ractor" exceptions. The concept "owner Ractor for classes/modules" solves this kind of exception. * Another idea for mutating the classes/modules is prohibit them on non-main Ractors because most of classes/modules are defined on the loading time on the main Ractor. However, it also prohibits `Class.new` in non-main Ractors, and it is common programming pattern on Ruby. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:126263] [Ruby Feature#22229] Allow GCI.escapeHTML to take a custom escape table
by byroot (Jean Boussier) 10 Aug '26

10 Aug '26

Issue #22229 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22229: Allow GCI.escapeHTML to take a custom escape table https://bugs.ruby-lang.org/issues/22229 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Use case `CGI.escapeHTML` has a fixed escape table: ```c HTML_ESCAPE('\'', "'"), HTML_ESCAPE('&', "&"), HTML_ESCAPE('"', """), HTML_ESCAPE('<', "<"), HTML_ESCAPE('>', ">"), ``` But in some context you may want to escape more or less characters than that, or escape them differently. One example of this is Active Support JSON serialization, which by defaults escape `<>&` as `\u003e\u003c\u0026`, to ensure that the generated JSON can safely be interpolated inside a `<script>` tag without causing XSS vulnerabilities. There's likely other use case as evidenced by the popularity of the `htmlentities` gem, which support several more escape tables. ### Why not `gsub` ? Today, this sort of escaping is performed using `gsub`, it works but is very noticeably slower than `CGI.escapeHTML` (see benchmarks on the PoC PR). This is because the only way to use `gsub` with an escape table is to craft a regexp: ```ruby def escape(string, table) pattern = Regexp.union(table.keys) string.gsub(pattern, table) end puts escape("<script>", "<" => "<", ">" => ">") ``` If `gsub` could be used directly with the escape table it would certainly make it faster: ```ruby puts "<script>".gsub("<" => "<", ">" => ">") ``` But compared to `CGI.escapeHTML` it would still need to deal with noticeably more scenarios (multi character search, etc), so would always be slower than a dedicated escaping method. `CGI.escapeHTML` can be more restrictive (single character search, etc). ### Specification ```ruby GCI.escapeHTML("</script>", "<" => "<", ">" => ">") ``` - The escape table keys must be single characters (currently ASCII only, but could be muti-byte characters if deemed necessary). ### Implementation ``` Pull Request: https://github.com/ruby/cgi/pull/55 (NB: it's at proof of concept / demo stage, if the feature is accepted I can polish it). -- https://bugs.ruby-lang.org/

3 6

[ruby-core:126355] [Ruby Bug#15599] Mixing autoload and require causes deadlock and incomplete definition.
by wanabe (_ wanabe) 10 Aug '26

10 Aug '26

Issue #15599 has been updated by wanabe (_ wanabe). Status changed from Open to Closed This issue was fixed between preview 2 and preview 3 of Ruby 3.3.0. ``` $ cat a.rb class A def a1() end end $ cat base.rb 1000.times do fork do autoload :A, './a' t1 = Thread.new { raise if A.instance_methods(false).size != 1 } t2 = Thread.new { require './a' } begin t1.join t2.join rescue Exception => e exit 1 end end end p Process.waitall.map {|_pid, status| status.success? ? :success : :failure }.group_by(&:itself).transform_values(&:size).to_a puts :fin $ docker run -it --rm -v.:/work -w/work --env ALL_RUBY_SINCE=3.2.10 rubylang/all-ruby /all-ruby/all-ruby base.rb ruby-3.2.10 #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 921], [:failure, 79]] fin ruby-3.2.11 #<Thread:0x00007eb67a448f68 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 922], [:failure, 78]] fin ruby-3.3.0-preview1 #<Thread:0x00007429d36e67e0 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 931], [:failure, 69]] fin ruby-3.3.0-preview2 #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 904], [:failure, 96]] fin ruby-3.3.0-preview3 [[:success, 1000]] fin ... ruby-4.0.6 [[:success, 1000]] fin ``` I found the commit is be1bbd5b7d40ad863ab35097765d3754726bbd54 == https://bugs.ruby-lang.org/issues/19842. I don't know why this is the case, but I suspect that the refactoring done to achieve the original goal (M:N threads) had a positive effect. ``` $ git checkout be1bbd5b7d40ad863ab35097765d3754726bbd54~ && make -j miniruby >/dev/null 2>&1 && ./miniruby base.rb HEAD is now at 096ee0648e2 Bump ruby/setup-ruby from 1.155.0 to 1.156.0 [[:success, 945], [:failure, 55]] fin $ git checkout be1bbd5b7d40ad863ab35097765d3754726bbd54 && make -j miniruby >/dev/null 2>&1 && ./miniruby base.rb Previous HEAD position was 096ee0648e2 Bump ruby/setup-ruby from 1.155.0 to 1.156.0 HEAD is now at be1bbd5b7d4 M:N thread scheduler for Ractors [[:success, 1000]] fin ``` ---------------------------------------- Bug #15599: Mixing autoload and require causes deadlock and incomplete definition. https://bugs.ruby-lang.org/issues/15599#change-118480 * Author: akr (Akira Tanaka) * Status: Closed * ruby -v: ruby 2.7.0dev (2019-02-11 trunk 67049) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- I found that mixing autoload and require causes deadlock and incomplete definition. ``` % cat a.rb class A def a1() end end % cat base.rb autoload :A, './a' t1 = Thread.new { p A.instance_methods(false) } t2 = Thread.new { require './a' } t1.join t2.join % ruby base.rb Traceback (most recent call last): 1: from base.rb:6:in `<main>' base.rb:6:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000055cc6943fde0 main thread:0x000055cc6935f4b0 * #<Thread:0x000055cc6938f190 sleep_forever> rb_thread_t:0x000055cc6935f4b0 native:0x00007f58d256eb40 int:0 base.rb:6:in `join' base.rb:6:in `<main>' * #<Thread:0x000055cc6968cfc8@base.rb:3 sleep_forever> rb_thread_t:0x000055cc69736180 native:0x00007f58ce7b3700 int:0 mutex:0x000055cc6943fde0 cond:1 depended by: tb_thread_id:0x000055cc6935f4b0 /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:3:in `block in <main>' * #<Thread:0x000055cc6968ccd0@base.rb:4 sleep_forever> rb_thread_t:0x000055cc6943fde0 native:0x00007f58ce5b1700 int:0 /tmp/a/a.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:4:in `block in <main>' % ruby base.rb [:a1] % ruby base.rb [] ``` The last run which prints [] means incomplete definition of A which a1 method is not defined. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121988] [Ruby Bug#21324] Namespace loads RubyGems in root Namespace but it should not
by Eregon (Benoit Daloze) 09 Aug '26

09 Aug '26

Issue #21324 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21324: Namespace loads RubyGems in root Namespace but it should not https://bugs.ruby-lang.org/issues/21324 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- RubyGems has tons of mutable state, isn't core library and isn't "builtin classes" either, so it should not be in root Namespace, as it is currently: ``` $ RUBY_NAMESPACE=1 ruby -ve 'ns = Namespace.new; p ns::Gem.equal?(Gem)' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. true ``` A concrete example of what breaks most likely due to this: ``` $ gem i delegate:0.3.1 $ RUBY_NAMESPACE=1 ruby -ve 'require "delegate"; p Delegator::VERSION; ns = Namespace.new; File.write "ns.rb", "gem %{delegate}, %{0.3.1}; require :delegate.to_s; p Delegator::VERSION"; ns.require "./ns"' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. "0.4.0" /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:2232:in 'Gem::Specification#check_version_conflict': can't activate delegate-0.3.1, already activated delegate-0.4.0 (Gem::LoadError) from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:1383:in 'Gem::Specification#activate' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'block in Kernel#gem' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Thread::Mutex#synchronize' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Kernel#gem' from /home/eregon/ns.rb:1:in '<top (required)>' from -e:1:in 'Namespace#require' from -e:1:in '<main>' ``` i.e. `ns` sees delegate-0.4.0 was loaded in main namespace but it shouldn't. Previously mentioned in https://bugs.ruby-lang.org/issues/21311#note-36 -- https://bugs.ruby-lang.org/

5 9

[ruby-core:126350] [Ruby Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread
by wanabe (_ wanabe) 09 Aug '26

09 Aug '26

Issue #15499 has been updated by wanabe (_ wanabe). It looks like it might be fixed with 1d4822a175a0dfccca8f252b0e757a1991bd54f9, but I'm not sure. ``` $ git checkout 1d4822a175a0dfccca8f252b0e757a1991bd54f9~; if make -j miniruby >/dev/null 2>&1; then ./miniruby -e 'Thread.new { Ractor.receive }; Ractor.receive' & CH=$! && sleep 1 && kill -INT $CH && sleep 1 && ps aux|grep "^[^ ]* *$CH" && kill -KILL $CH; fi HEAD is now at 2fee379f8f0 Checkout .github on omnibus result for notifications [1] 797951 wanabe 797951 0.0 0.0 526288 9920 pts/7 Sl 20:38 0:00 ./miniruby -e Thread.new{ Ractor.receive }; Ractor.receive [1]+ Killed ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' $ git checkout 1d4822a175a0dfccca8f252b0e757a1991bd54f9; if make -j miniruby >/dev/null 2>&1; then ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' & CH=$! && sleep 1 && kill -INT $CH && sleep 1 && ps aux|grep "^[^ ]* *$CH" && kill -KILL $CH; fi Previous HEAD position was 2fee379f8f0 Checkout .github on omnibus result for notifications HEAD is now at 1d4822a175a Get ractor message passing working with > 1 thread sending/receiving values in same ractor [1] 798878 <internal:ractor>:431:in 'Ractor.receive': Interrupt from -e:1:in '<main>' [1]+ Interrupt ./miniruby -e 'Thread.new{ Ractor.receive }; Ractor.receive' ``` ---------------------------------------- Bug #15499: Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread https://bugs.ruby-lang.org/issues/15499#change-118474 * Author: apolcyn (alex polcyn) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * ruby -v: master * Backport: 2.4: DONTNEED, 2.5: DONTNEED, 2.6: DONE ---------------------------------------- This issue was noticed when trying to add ruby 2.6 support to the "grpc" ruby gem (this gem is a native C-extension), and was caught by a unit test. There are several APIs on the grpc ruby gem (https://github.com/grpc/grpc/tree/master/src/ruby) that invoke "rb_thread_call_without_gvl" on the current thread, doing a blocking operation in the "without gvl" callback and cancel that blocking operation in the "unblocking function". These APIs work in ruby versions prior to ruby 2.6 (e.g. ruby 2.5), but have problems when used on ruby 2.6 Minimal repro: My system: ``` > lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.6 (stretch) Release: 9.6 Codename: stretch > ruby -v ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux # I installed ruby 2.6.0 with rvm - https://rvm.io/rvm/install > GRPC_CONFIG=dbg gem install grpc --platform ruby # build grpc gem from source with debug symbols ``` ruby script, "repro.rb" that looks like this: ```ruby require 'grpc' ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) ``` Run "ruby repro.rb" with an interactive shell, and it will hang there. At this point, ctrl^C the process, and it will not terminate. What should happen is this unblocking func should be invoked: https://github.com/grpc/grpc/blob/master/src/ruby/ext/grpc/rb_channel.c#L354, but as seen with logging or debuggers, that unblocking func is never ran. Thus the blocking operation never completes and the main thread is stuck. When the same repro.rb is ran on e.g. ruby 2.5.3 or ruby 2.4.1, the blocking operation is unblocked and the process terminates, as expected, when sending it a SIGINT. Also note that if the blocking operation is put in a background thread, e.g. with this script: ```ruby require 'grpc' th = Thread.new do ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) end th.join ``` then "unblocking" functions will in fact be invoked upon sending the process a SIGINT, so this looks like a problem specifically with rb_thread_call_without_gvl being used on the main thread. Please let me know and I can provide more details or alternative repro cases. Thanks in advance. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121478] [Ruby Bug#21206] Segmentation fault on ISeq#to_binary
by shyouhei (Shyouhei Urabe) 09 Aug '26

09 Aug '26

Issue #21206 has been reported by shyouhei (Shyouhei Urabe). ---------------------------------------- Bug #21206: Segmentation fault on ISeq#to_binary https://bugs.ruby-lang.org/issues/21206 * Author: shyouhei (Shyouhei Urabe) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Found this SEGV using bootsnap. This could well be architecture dependent because of ISeqs being so by nature. Also this doesn't happen when the ISeq is created using `compile_prism`. ``` $ ruby -ve 'RubyVM::InstructionSequence.compile_parsey("def f(g) = each {nil rescue g+it}").to_binary' ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] -e:1: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM +GC [aarch64-linux-gnu] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 CFUNC :to_binary c:0002 p:0008 s:0006 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:000190 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -e:1:in 'to_binary' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000ffff8a15d0a8 x2: 0x0000000000000000 x3: 0x0000000000000003 x4: 0x0000000000000000 x5: 0x0000ffffa4346b50 x6: 0x0000000000000005 x7: 0x00000000fffffffe x18: 0x000000000116810c x19: 0x0000ffff8a15d0a8 x20: 0x0000000000000000 x21: 0x0000000000000001 x22: 0x0000ffffc0f0d968 x23: 0x0000ffffc0f0d4c0 x24: 0x0000000000000018 x25: 0x0000ffffa3c98530 x26: 0x0000000000000000 x27: 0x0000000000000002 x28: 0x0000ffffc0f0d4e8 x29: 0x0000ffffc0f0d410 sp: 0x0000ffffc0f0d410 fau: 0x0000000000000000 -- C level backtrace information ------------------------------------------- /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e8ff84) [0xffffa3e8ff84] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e95514) [0xffffa3e95514] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3ce760c) [0xffffa3ce760c] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(0xffffa3e0de88) [0xffffa3e0de88] linux-vdso.so.1(__kernel_rt_sigreturn+0x0) [0xffffa43447a0] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(rb_str_cmp+0x24) [0xffffa3e17d94] [0xffffa3980b9c] [0xffffa3980efc] [0xffffa3f418c8] [0xffffa3c98d4c] [0xffffa3da2484] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(rb_st_foreach+0x44) [0xffffa3e06944] [0xffffa3f213e4] [0xffffa3d46ea4] [0xffffa3e6c92c] [0xffffa3e767a8] [0xffffa3e8cae8] [0xffffa3ce6ac4] /lib/aarch64-linux-gnu/libruby-3.4.so.3.4(ruby_run_node+0x9c) [0xffffa3cebba0] [0xaaaae2be0b30] [0xffffa39684c4] [0xffffa3968598] [0xaaaae2be0bb0] -- Other runtime information ----------------------------------------------- * Loaded script: -e * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so 7 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so 8 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/rbconfig.rb 9 /usr/lib/ruby/3.4.0/rubygems/compatibility.rb 10 /usr/lib/ruby/3.4.0/rubygems/defaults.rb 11 /usr/lib/ruby/3.4.0/rubygems/deprecate.rb 12 /usr/lib/ruby/3.4.0/rubygems/errors.rb 13 /usr/lib/ruby/3.4.0/rubygems/target_rbconfig.rb 14 /usr/lib/ruby/3.4.0/rubygems/unknown_command_spell_checker.rb 15 /usr/lib/ruby/3.4.0/rubygems/exceptions.rb 16 /usr/lib/ruby/3.4.0/rubygems/basic_specification.rb 17 /usr/lib/ruby/3.4.0/rubygems/stub_specification.rb 18 /usr/lib/ruby/3.4.0/rubygems/platform.rb 19 /usr/lib/ruby/3.4.0/rubygems/specification_record.rb 20 /usr/lib/ruby/3.4.0/rubygems/util/list.rb 21 /usr/lib/ruby/3.4.0/rubygems/version.rb 22 /usr/lib/ruby/3.4.0/rubygems/requirement.rb 23 /usr/lib/ruby/3.4.0/rubygems/specification.rb 24 /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb 25 /usr/lib/ruby/3.4.0/rubygems/util.rb 26 /usr/lib/ruby/3.4.0/rubygems/dependency.rb 27 /usr/lib/ruby/3.4.0/rubygems/core_ext/kernel_gem.rb 28 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so 29 /usr/lib/ruby/3.4.0/monitor.rb 30 /usr/lib/ruby/3.4.0/rubygems.rb 31 /usr/lib/ruby/3.4.0/bundled_gems.rb 32 /usr/lib/ruby/3.4.0/rubygems/path_support.rb 33 /usr/lib/ruby/3.4.0/error_highlight/version.rb 34 /usr/lib/ruby/3.4.0/error_highlight/base.rb 35 /usr/lib/ruby/3.4.0/error_highlight/formatter.rb 36 /usr/lib/ruby/3.4.0/error_highlight/core_ext.rb 37 /usr/lib/ruby/3.4.0/error_highlight.rb 38 /usr/lib/ruby/3.4.0/did_you_mean/version.rb 39 /usr/lib/ruby/3.4.0/did_you_mean/core_ext/name_error.rb 40 /usr/lib/ruby/3.4.0/did_you_mean/levenshtein.rb 41 /usr/lib/ruby/3.4.0/did_you_mean/jaro_winkler.rb 42 /usr/lib/ruby/3.4.0/did_you_mean/spell_checker.rb 43 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 44 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 45 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/name_error_checkers.rb 46 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/method_name_checker.rb 47 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/key_error_checker.rb 48 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/null_checker.rb 49 /usr/lib/ruby/3.4.0/did_you_mean/tree_spell_checker.rb 50 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/require_path_checker.rb 51 /usr/lib/ruby/3.4.0/did_you_mean/spell_checkers/pattern_key_name_checker.rb 52 /usr/lib/ruby/3.4.0/did_you_mean/formatter.rb 53 /usr/lib/ruby/3.4.0/did_you_mean.rb 54 /usr/lib/ruby/3.4.0/syntax_suggest/core_ext.rb * Process memory map: aaaae2be0000-aaaae2be1000 r-xp 00000000 00:34 763738 /usr/bin/ruby3.4 aaaae2bff000-aaaae2c00000 r--p 0000f000 00:34 763738 /usr/bin/ruby3.4 aaaae2c00000-aaaae2c01000 rw-p 00010000 00:34 763738 /usr/bin/ruby3.4 aaab18253000-aaab18545000 rw-p 00000000 00:00 0 [heap] ffff87c00000-ffff881f3000 r--s 00000000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffff88200000-ffff88201000 ---p 00000000 00:00 0 ffff88201000-ffff882a2000 rw-p 00000000 00:00 0 ffff882a2000-ffff882a3000 ---p 00000000 00:00 0 ffff882a3000-ffff88344000 rw-p 00000000 00:00 0 ffff88344000-ffff88345000 ---p 00000000 00:00 0 ffff88345000-ffff883e6000 rw-p 00000000 00:00 0 ffff883e6000-ffff883e7000 ---p 00000000 00:00 0 ffff883e7000-ffff88488000 rw-p 00000000 00:00 0 ffff88488000-ffff88489000 ---p 00000000 00:00 0 ffff88489000-ffff8852a000 rw-p 00000000 00:00 0 ffff8852a000-ffff8852b000 ---p 00000000 00:00 0 ffff8852b000-ffff885cc000 rw-p 00000000 00:00 0 ffff885cc000-ffff885cd000 ---p 00000000 00:00 0 ffff885cd000-ffff8866e000 rw-p 00000000 00:00 0 ffff8866e000-ffff8866f000 ---p 00000000 00:00 0 ffff8866f000-ffff88710000 rw-p 00000000 00:00 0 ffff88710000-ffff88711000 ---p 00000000 00:00 0 ffff88711000-ffff887b2000 rw-p 00000000 00:00 0 ffff887b2000-ffff887b3000 ---p 00000000 00:00 0 ffff887b3000-ffff88854000 rw-p 00000000 00:00 0 ffff88854000-ffff88855000 ---p 00000000 00:00 0 ffff88855000-ffff888f6000 rw-p 00000000 00:00 0 ffff888f6000-ffff888f7000 ---p 00000000 00:00 0 ffff888f7000-ffff88998000 rw-p 00000000 00:00 0 ffff88998000-ffff88999000 ---p 00000000 00:00 0 ffff88999000-ffff88a3a000 rw-p 00000000 00:00 0 ffff88a3a000-ffff88a3b000 ---p 00000000 00:00 0 ffff88a3b000-ffff88adc000 rw-p 00000000 00:00 0 ffff88adc000-ffff88add000 ---p 00000000 00:00 0 ffff88add000-ffff88b7e000 rw-p 00000000 00:00 0 ffff88b7e000-ffff88b7f000 ---p 00000000 00:00 0 ffff88b7f000-ffff88c20000 rw-p 00000000 00:00 0 ffff88c20000-ffff88c21000 ---p 00000000 00:00 0 ffff88c21000-ffff88cc2000 rw-p 00000000 00:00 0 ffff88cc2000-ffff88cc3000 ---p 00000000 00:00 0 ffff88cc3000-ffff88d64000 rw-p 00000000 00:00 0 ffff88d64000-ffff88d65000 ---p 00000000 00:00 0 ffff88d65000-ffff88e06000 rw-p 00000000 00:00 0 ffff88e06000-ffff88e07000 ---p 00000000 00:00 0 ffff88e07000-ffff88ea8000 rw-p 00000000 00:00 0 ffff88ea8000-ffff88ea9000 ---p 00000000 00:00 0 ffff88ea9000-ffff88f4a000 rw-p 00000000 00:00 0 ffff88f4a000-ffff88f4b000 ---p 00000000 00:00 0 ffff88f4b000-ffff88fec000 rw-p 00000000 00:00 0 ffff88fec000-ffff88fed000 ---p 00000000 00:00 0 ffff88fed000-ffff8908e000 rw-p 00000000 00:00 0 ffff8908e000-ffff8908f000 ---p 00000000 00:00 0 ffff8908f000-ffff89130000 rw-p 00000000 00:00 0 ffff89130000-ffff89131000 ---p 00000000 00:00 0 ffff89131000-ffff891d2000 rw-p 00000000 00:00 0 ffff891d2000-ffff891d3000 ---p 00000000 00:00 0 ffff891d3000-ffff89274000 rw-p 00000000 00:00 0 ffff89274000-ffff89275000 ---p 00000000 00:00 0 ffff89275000-ffff89316000 rw-p 00000000 00:00 0 ffff89316000-ffff89317000 ---p 00000000 00:00 0 ffff89317000-ffff893b8000 rw-p 00000000 00:00 0 ffff893b8000-ffff893b9000 ---p 00000000 00:00 0 ffff893b9000-ffff8945a000 rw-p 00000000 00:00 0 ffff8945a000-ffff8945b000 ---p 00000000 00:00 0 ffff8945b000-ffff894fc000 rw-p 00000000 00:00 0 ffff894fc000-ffff894fd000 ---p 00000000 00:00 0 ffff894fd000-ffff8959e000 rw-p 00000000 00:00 0 ffff8959e000-ffff8959f000 ---p 00000000 00:00 0 ffff8959f000-ffff89640000 rw-p 00000000 00:00 0 ffff89800000-ffff89810000 ---p 00000000 00:00 0 ffff89810000-ffff8a010000 rw-p 00000000 00:00 0 ffff8a0d0000-ffff8a0e0000 rw-p 00000000 00:00 0 ffff8a0ef000-ffff8a120000 rw-p 00000000 00:00 0 ffff8a120000-ffff8a122000 r-xp 00000000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a122000-ffff8a13f000 ---p 00002000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a13f000-ffff8a140000 r--p 0000f000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a140000-ffff8a141000 rw-p 00010000 00:34 763838 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/monitor.so ffff8a150000-ffffa3600000 rw-p 00000000 00:00 0 ffffa3610000-ffffa36d0000 rw-p 00000000 00:00 0 ffffa36d0000-ffffa36d2000 r-xp 00000000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36d2000-ffffa36ef000 ---p 00002000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36ef000-ffffa36f0000 r--p 0000f000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa36f0000-ffffa36f1000 rw-p 00010000 00:34 763811 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/trans/transdb.so ffffa3700000-ffffa3710000 rw-p 00000000 00:00 0 ffffa3710000-ffffa3712000 r-xp 00000000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3712000-ffffa372f000 ---p 00002000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa372f000-ffffa3730000 r--p 0000f000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3730000-ffffa3731000 rw-p 00010000 00:34 763767 /usr/lib/aarch64-linux-gnu/ruby/3.4.0/enc/encdb.so ffffa3740000-ffffa3790000 rw-p 00000000 00:00 0 ffffa379e000-ffffa3900000 rw-p 00000000 00:00 0 ffffa3900000-ffffa391f000 r-xp 00000000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa391f000-ffffa392f000 ---p 0001f000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa392f000-ffffa3930000 r--p 0001f000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa3930000-ffffa3931000 rw-p 00020000 00:34 566619 /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 ffffa3940000-ffffa3ada000 r-xp 00000000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3ada000-ffffa3aed000 ---p 0019a000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3aed000-ffffa3af0000 r--p 0019d000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3af0000-ffffa3af2000 rw-p 001a0000 00:34 770271 /usr/lib/aarch64-linux-gnu/libc.so.6 ffffa3af2000-ffffa3afe000 rw-p 00000000 00:00 0 ffffa3b00000-ffffa3b85000 r-xp 00000000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3b85000-ffffa3b9f000 ---p 00085000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3b9f000-ffffa3ba0000 r--p 0008f000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3ba0000-ffffa3ba1000 rw-p 00090000 00:34 770303 /usr/lib/aarch64-linux-gnu/libm.so.6 ffffa3bb0000-ffffa3bdd000 r-xp 00000000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bdd000-ffffa3bef000 ---p 0002d000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bef000-ffffa3bf0000 r--p 0002f000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bf0000-ffffa3bf1000 rw-p 00030000 00:34 566603 /usr/lib/aarch64-linux-gnu/libcrypt.so.1.1.0 ffffa3bf1000-ffffa3bf9000 rw-p 00000000 00:00 0 ffffa3c00000-ffffa41cb000 r-xp 00000000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41cb000-ffffa41d6000 ---p 005cb000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41d6000-ffffa41f0000 r--p 005d6000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41f0000-ffffa41f1000 rw-p 005f0000 00:34 763745 /usr/lib/aarch64-linux-gnu/libruby-3.4.so.3.4.2 ffffa41f1000-ffffa4206000 rw-p 00000000 00:00 0 ffffa420f000-ffffa4220000 r--s 00000000 00:34 763738 /usr/bin/ruby3.4 ffffa4220000-ffffa4230000 rw-p 00000000 00:00 0 ffffa4230000-ffffa42aa000 r-xp 00000000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42aa000-ffffa42bf000 ---p 0007a000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42bf000-ffffa42c0000 r--p 0007f000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42c0000-ffffa42c1000 rw-p 00080000 00:34 767074 /usr/lib/aarch64-linux-gnu/libgmp.so.10.5.0 ffffa42d0000-ffffa42ea000 r-xp 00000000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa42ea000-ffffa42ff000 ---p 0001a000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa42ff000-ffffa4300000 r--p 0001f000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa4300000-ffffa4301000 rw-p 00020000 00:34 566707 /usr/lib/aarch64-linux-gnu/libz.so.1.3 ffffa4307000-ffffa432e000 r-xp 00000000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffa4339000-ffffa433d000 rw-p 00000000 00:00 0 ffffa4340000-ffffa4342000 rw-p 00000000 00:00 0 ffffa4342000-ffffa4344000 r--p 00000000 00:00 0 [vvar] ffffa4344000-ffffa4345000 r-xp 00000000 00:00 0 [vdso] ffffa4345000-ffffa4347000 r--p 0002e000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffa4347000-ffffa4349000 rw-p 00030000 00:34 769991 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ffffc0eef000-ffffc0f10000 rw-p 00000000 00:00 0 [stack] Segmentation fault ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126346] [Ruby Bug#22218] Line TracePoint misses executed loop condition after a guard
by nagachika (Tomoyuki Chikanaga) 09 Aug '26

09 Aug '26

Issue #22218 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED to 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED ruby_3_4 commit:7096aad15fc249bc04ddc6335156ba90e68dbdd2 merged revision(s) commit:79e6d37b5569be4c772e9d41e8a5447e82c09683. ---------------------------------------- Bug #22218: Line TracePoint misses executed loop condition after a guard https://bugs.ruby-lang.org/issues/22218#change-118464 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: DONE, 4.0: REQUIRED ---------------------------------------- `TracePoint.new(:line)` can miss the line event for an executed loop condition when the loop follows a conditional guard. This is related to [Bug #15980](https://bugs.ruby-lang.org/issues/15980), which fixed the same control-flow problem for line coverage. The coverage-specific workaround does not apply to ordinary line TracePoint consumers, so TracePoint and Coverage can still disagree. ## Affected versions This affects Ruby 3.3 and later. The behavior was reproduced on Ruby 3.4.4 and Ruby 4.0.5, both of which report `[1, 3]`. Ruby 3.3.0 through 3.3.11 retain the same coverage-only compiler guard; the source explicitly notes that the TracePoint line event does not occur. Ruby 4.1 development versions are also affected without the proposed patch. ## Reproduction ```ruby source = <<~RUBY raise if 1 == 2 while true break end RUBY lines = [] TracePoint.new(:line) do |trace| lines << trace.lineno if trace.path == "example.rb" end.enable do eval(source, binding, "example.rb") end p lines ``` ### Actual result ```ruby [1, 3] ``` ### Expected result ```ruby [1, 2, 3] ``` The same problem occurs with a non-constant predicate, for example: ```ruby def read return if @finished while chunk = super consume(chunk) end end ``` ## Cause Jump-to-jump peephole optimization retargets the conditional branch past the synthetic jump carrying the line event. As a result, execution reaches the loop body without visiting the event-bearing instruction. ## Proposed Fix The proposed fix is [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122). Ruby already stops this jump-to-jump optimization when line coverage is enabled and the skipped jump has event flags. The patch generalizes that existing guard: it skips this specific retargeting whenever the intermediate jump carries `RUBY_EVENT_LINE` or `RUBY_EVENT_COVERAGE_LINE`, regardless of whether coverage is active. Other jump-to-jump folding remains enabled. The change only retains the event-bearing jump that TracePoint must visit; it does not add trace-edge metadata or require new VM, YJIT, or ZJIT handling. This is the smaller alternative suggested in the discussion of [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825). ### Performance The retained jump costs one additional YARV dispatch when the interpreter traverses an affected edge. Performance-sensitive JIT execution can optimize away the extra control-flow overhead: YJIT emits no machine jump when it can place the target block next, while ZJIT cleans up the jump chain in its control-flow graph. The following results compare Ruby immediately before and after the patch on an Apple M4 Pro. Each result is the median of 9 or 11 samples after 3 warmups: | Targeted benchmark | Baseline | Patched | Change | |---|---:|---:|---:| | Hot affected edge, interpreter | 46.20 M iterations/s | 45.74 M iterations/s | -1.0% | | Minimal guarded reader, interpreter | 30.95 M calls/s | 30.13 M calls/s | -2.7% | | Minimal guarded reader, YJIT | 272.56 M calls/s | 272.56 M calls/s | 0.0% | | Minimal guarded reader, ZJIT | 435.34 M calls/s | 436.89 M calls/s | +0.4% | For a synthetic hot-edge benchmark, two long YJIT runs in opposite order varied between -0.5% and +0.4%, and ZJIT differed by +0.04%. There was therefore no repeatable JIT regression. The interpreter figures are deliberately concentrated worst cases where every iteration or call traverses the affected edge. ## Related work - Previous coverage issue: [Bug #15980](https://bugs.ruby-lang.org/issues/15980) - Earlier edge-metadata approach: [ruby/ruby#17825](https://github.com/ruby/ruby/pull/17825) - Selective peephole fix: [ruby/ruby#18122](https://github.com/ruby/ruby/pull/18122) -- https://bugs.ruby-lang.org/

1 0