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

[ruby-core:126883] [Ruby Feature#22392] Allow refinements to define && and ||
by shugo (Shugo Maeda) 30 Sep '26

30 Sep '26

Issue #22392 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22392: Allow refinements to define && and || https://bugs.ruby-lang.org/issues/22392 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 4.1 ---------------------------------------- ## Abstract I propose to allow refinements to define `&&` and `||`, so that DSLs can build expressions such as `name == "x" && age > 20`. The right-hand side is evaluated before the method is called, so short-circuiting is not customizable. ## Motivation Query builders and similar DSLs want to capture boolean expressions written in a block: ```ruby User.where { name == "x" && age > 20 } ``` Today such DSLs have to use `&` and `|` instead, which bind tighter than `==` and `>`, so every operand needs parentheses: `(name == "x") & (age > 20)`. ## Proposal `&&` and `||` can be defined as methods in refinements: ```ruby module QueryDSL refine Condition do def &&(other) = And.new(self, other) def ||(other) = Or.new(self, other) end end def User.where(&block) = build(block.refined(QueryDSL).call) User.where { name == "x" && age > 20 } # => And(Eq(name, "x"), Gt(age, 20)) ``` Semantics of `a && b` (`a || b` is symmetric): * If the class of `a` has `&&` defined by a refinement active in the current scope, `b` is evaluated and `a.&&(b)` is the result. * Otherwise, the behavior is unchanged. With a hook, the result is always `a.&&(b)`, which never short-circuits. Details: * `&&` and `||` can be defined only in refinements. Defining them elsewhere raises NameError. A hook changes when the right-hand side is evaluated, so its effect should be limited to code that opted in by `using` or `Proc#refined`, rather than reaching every method that receives such an object. There are no default methods such as `Object#&&`, so `super` is not available in a hook. * The hooks also apply in conditions such as `if a && b`, so that `x = a && b; if x` and `if a && b` behave the same. * `and` and `or` behave the same as `&&` and `||`. * `&&=` and `||=` do not use the hooks, to keep the memoization idiom. * `def &&`, `def ||`, `:&&` and `:||` become valid syntax. ## Prior art Scala and Swift treat `&&` and `||` as ordinary methods, so DSLs such as Slick define them on their own types, and the compiler resolves them statically. C# lets a type define `&`, `|`, `true` and `false`, and expands `x && y` to `T.false(x) ? x : x & y`. C++ allows overloading `&&` globally, which is discouraged because short-circuiting is lost for every user of the type. Python, Kotlin, Rust and Julia don't allow it; their DSLs use `&` and `|` with the same precedence problem as in Ruby, and PEP 335, which proposed overloadable `and`/`or`, was rejected for the cost it added to every `and`/`or` and for its complexity. This proposal follows Scala and Swift in dispatching on the receiver, at run time since Ruby is dynamically typed, and limits the definitions to refinements so that, unlike in C++, code outside the DSL keeps short-circuiting. Code that doesn't use the hooks pays nothing, unlike in PEP 335. The right-hand side is evaluated eagerly rather than passed lazily: a hook that builds an expression needs its value in any case, so laziness would add complexity without a use. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126882] [Ruby Bug#22391] Fix propagation of `ERRNO` in `rb_io_maybe_wait`.
by ioquatix (Samuel Williams) 29 Sep '26

29 Sep '26

Issue #22391 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22391: Fix propagation of `ERRNO` in `rb_io_maybe_wait`. https://bugs.ruby-lang.org/issues/22391 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a write returns `EAGAIN`, we call `rb_io_wait()`: io_write() io_fwrite() io_binwrite() io_binwrite_string() io_binwrite_string_internal() ... rb_io_maybe_wait_writable() rb_io_maybe_wait() return rb_io_wait(io, events, timeout) if this wait also fails, it bubbles up to io_write() which reports it: io_write() rb_sys_fail_on_write() rb_syserr_new_path_in() rb_syserr_new_path(errno, ...) `rb_syserr_new_path_in` (after macro resolution) checks for a 0 error code and aborts in that case: if (n == 0) { const char *s = !NIL_P(path) ? RSTRING_PTR(path) : ""; if (!func_name) func_name = "(null)"; rb_bug("rb_sys_fail_path_in(%s, %s) - errno == 0", func_name, s); } Unfortunately, `rb_io_wait()` can invoke the fiber scheduler, running arbitrary code that can clobber `errno` and trigger this `rb_bug()`. Fix this by preserving `errno` explicitly across the `rb_io_wait()` call. https://github.com/ruby/ruby/pull/19121 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126879] [Ruby Bug#22389] Hang on GC.compact
by rkh (Konstantin Haase) 29 Sep '26

29 Sep '26

Issue #22389 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22389: Hang on GC.compact https://bugs.ruby-lang.org/issues/22389 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-29T07:26:07Z master 64a4a372d7) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code works on 4.0.7 but hangs on 4.1.0dev (64a4a372d7): ```ruby ready = Ractor::Port.new Ractor.new(ready) do |port| Array.new(10_000) { Object.new } port << true Ractor.receive end ready.receive Thread.new { GC.compact }.join GC.compact ``` A native sample of the hung process shows: ```text gc_start_global gc_compact_finish gc_update_references_heap rb_iseq_mark_and_move rb_gc_mark_and_move rb_gc_impl_location + 180 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126880] [Ruby Bug#22390] ruby 3.4 -> 4.0 upgrade GC changes causing >2x RSS increase
by chucke (Tiago Cardoso) 29 Sep '26

29 Sep '26

Issue #22390 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22390: ruby 3.4 -> 4.0 upgrade GC changes causing >2x RSS increase https://bugs.ruby-lang.org/issues/22390 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I've been trying to upgrade a fairly sizeable monolith, which has been running on ruby 3.4.10 in production, to ruby 4 (have been targeting 4.0.6 more specifically, although the below should apply the same to 4.0.7). While we didn't experience anything out of the ordinary in staging, unfortunately, we started seeing our more intensive workloads (job processors) grow in memory usage over the first 40m of running on ruby 4, up to the point where the servers would hit OOM, at which point we decided to rollback and investigate. This workload calls `Process.warmup` after booting the application and then fork multiple processes (not sure if this information is relevant). We figured out that the culprit of this change in GC behaviour was [this commit](https://github.com/ruby/ruby/commit/d4406f0627c78af31e61f9e07dda915… from @peter.zhu; this commit actually another bug for which we have a mitigation in ruby 3.4, however it changed quite a few more things in the heuristics used to decide when to give empty pages back to the OS. Before the commit, `heap_pages_free_unused_pages` used `objspace->heap_pages.allocatable_slots` to decide, and this number would be reset to 0 on every sweep, and grow when expanding the heap, which resulted in every empty page being freed on every major GC. After the commit, this changed to using `heap_pages_freeable_pages`, which gets computed on every major GC, and matched against GC_HEAP_FREE_SLOTS_MAX_RATIO. In our case at least, this doesn't work out, because in the aforementioned workload, `objspace_available_slots` grows at the same pace as `heap_pages_freeable_pages`; this makes it so that the 65% max ratio is never reached for this type of steadily churning live sets; by the time the size pools settle, the remainder of empty pages is never given back. I also tried to pull claude to figure some of this out, and it mentioned that the per pool 20% reservation alongside the single (per process) empty pages management somehow plays a role, but I couldn't make sense of whether that was legit or just an hallucination. I'm attaching a script which I coded with some AI help to roughly mimic the objects being created per job iteration. Bear in mind that, in our case in production, we're talking about many more (OOM hits at ~5Gb, and we've seen the ruby 4 builds grow up to 4Gb before we rolled back), but this represents the type of objects created in a way that makes each of the pools grow independently. If you run it locally, you should see the ruby 4 example use ~2x the memory, mostly because of the empty pages being kept around; major gcs will sometimes free them back to the OS, but I suspect that the reason for it was some other condition triggering a major GC (oldmalloc perhaps?) and causing `heap_pages_freeable_pages` to be recalculated as a result. We continue experimenting with the GC knobs to see if we can find a combination which would allow us to run ruby 4 in production. We're looking at pre-allocating a bunch of slots in pools 1-5 (as per upper bounds from observations using `GC.stat_heap`), while lowering GC_HEAP_OLDOBJECT_LIMIT_FACTOR to force major GC to run more often (a tad more, not too much, not to hurt latency) and hopefully updating freeable pages stats, while also lowering GC_HEAP_FREE_SLOTS_MAX_RATIO as well to a value that makes more sense. If anyone has suggestions on how to further get to optimal values, I'm all ears. Still, while I accept that special workloads require special tuning, I don't find this one unusual enough to justify this type of memory usage increase just due to a ruby upgrade, hence why I file this as a bug. ---Files-------------------------------- repro_gc.rb (4.56 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126878] [Ruby Bug#22388] Use-after-free when an Enumerable retains its `each` block
by nobu (Nobuyoshi Nakada) 29 Sep '26

29 Sep '26

Issue #22388 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22388: Use-after-free when an Enumerable retains its `each` block https://bugs.ruby-lang.org/issues/22388 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Some `Enumerable` methods pass a pointer to stack-allocated state to `rb_block_call`. If an implementation of `each` retains the given block and invokes it after the `Enumerable` method has returned, the callback accesses invalid stack memory. This affects `Enumerable#min(n)`, `#max(n)`, `#min_by(n)`, and `#max_by(n)`. It also affects `Enumerable#sum`. The following example reproduces the problem: ````ruby class DeferredEach include Enumerable attr_reader :each_block def each(&block) @each_block = block end end enum = DeferredEach.new enum.min(2) GC.start enum.each_block.call(1) ```` The same problem exists in the other methods: ````ruby %i[min max min_by max_by].each do |method| enum = DeferredEach.new enum.public_send(method, 2) { |x| x } GC.start enum.each_block.call(1) end ```` `Enumerable#sum` can be reproduced as follows: ````ruby enum = DeferredEach.new enum.sum { |x| x * 2 } GC.start enum.each_block.call(1) ```` Depending on the stack contents and GC timing, these examples may crash, raise an unrelated exception, or appear to work. The behavior is undefined because the retained callback refers to state whose lifetime ended when the original method returned. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111740] [Ruby master Bug#19325] Windows support lacking.
by dsisnero (Dominic Sisneros) 29 Sep '26

29 Sep '26

Issue #19325 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Bug #19325: Windows support lacking. https://bugs.ruby-lang.org/issues/19325 * Author: dsisnero (Dominic Sisneros) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2. -- https://bugs.ruby-lang.org/

11 13

[ruby-core:126876] [Ruby Feature#18439] YJIT: Support Microsoft x86 calling convention
by hsbt (Hiroshi SHIBATA) 29 Sep '26

29 Sep '26

Issue #18439 has been updated by hsbt (Hiroshi SHIBATA). I made YJIT work on mswin x64 in https://github.com/ruby/ruby/pull/19114. It follows the Win64 calling convention and registers unwind info for JIT code, as discussed here, and passes `nmake check` with YJIT enabled. YJIT is about 2x faster than the interpreter on ruby-bench's headline benchmarks on mswin. I'd like to ship this in Ruby 4.1 and will maintain the Windows side, so I'd appreciate reviews from the JIT team. ---------------------------------------- Feature #18439: YJIT: Support Microsoft x86 calling convention https://bugs.ruby-lang.org/issues/18439#change-119247 * Author: usa (Usaku NAKAMURA) * Status: Assigned * Assignee: jit ---------------------------------------- I heard that supporting YJIT for VC++ needs mmap from k0kubun-san, so I implemented tiny mmap emulation on Windows and committed it to master. And, I found we need more changes to actually enabled YJIT for VC++, at least: - YJIT requires `OPT_DIRECT_THREADED_CODE` or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq()`. Really? - Maybe ABI deffers between VC++ and YJIT's expectation. Can I get support to fix above? -- https://bugs.ruby-lang.org/

1 0

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

28 Sep '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/

5 8

[ruby-core:126871] [Ruby Bug#22387] str_shared_replace incorrectly recalculates termlen
by rwstauner (Randy Stauner) 28 Sep '26

28 Sep '26

Issue #22387 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22387: str_shared_replace incorrectly recalculates termlen https://bugs.ruby-lang.org/issues/22387 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- This ruby snippet crashes under ASan ```ruby s = ("\u{30AF}" * 7).encode("UTF-16LE").b s.force_encoding("UTF-16LE") s.encode!("UTF-8") # 21 bytes in a 22-byte malloc, capa now claims 22 s << "x" # fits, per capa, then NUL terminator written at [22] ``` str_shared_replace uses rb_enc_associate which recalculates termlen based on the old str even though the termlen of the new str was already used for the copy. We can just switch that to rb_enc_raw_set to fix. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:126866] [Ruby Bug#22386] Segfault when a Ractor helper thread reports an exception during teardown
by rkh (Konstantin Haase) 28 Sep '26

28 Sep '26

Issue #22386 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22386: Segfault when a Ractor helper thread reports an exception during teardown https://bugs.ruby-lang.org/issues/22386 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-27T05:30:49Z master f6ff9e7d02) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.1-dev can segfault when a thread inside a terminating Ractor raises an exception in an `ensure` block. Automatic thread exception reporting tries to load error-formatting code through `require`. The require path creates an internal Ractor port after the Ractor's port table has been freed. Creating a `Ractor::Port` directly in the same teardown context also segfaults, even with automatic exception reporting disabled. Script to reproduce the issue: ```ruby worker = Ractor.new do ready = Thread::Queue.new Thread.new do begin ready << true sleep ensure Object.new.missing_method_during_teardown end end ready.pop :done end worker.value ``` Running the script on Ruby 4.1-dev gives a segmentation fault output and then hangs. ``` #<Thread:0x0000000122aa0190 issue.rb:3 aborting> terminated with exception (report_on_exception is true): [BUG] Segmentation fault at 0x0000000000000018 ruby 4.1.0dev (2026-09-27T05:30:49Z master f6ff9e7d02) +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0002 p:---- s:0006 e:000005 l:y b:0001 r:0x0 CFUNC :detailed_message c:0001 p:---- s:0003 e:000002 l:y b:---- r:0x0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- issue.rb:0:in 'detailed_message' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 2 -- Machine register context ------------------------------------------------ x0: 0x0000000000000000 x1: 0x0000000000000001 x2: 0x000000083b2cf0e0 x3: 0x0000000000000000 x4: 0x0000000000000001 x5: 0x0000000000000000 x6: 0xffffffffbfc007ff x7: 0xfffff0003ffff800 x18: 0x0000000000000000 x19: 0x0000000122ac09c0 x20: 0x000000083adced00 x21: 0x0000000000000000 x22: 0x0000000000000001 x23: 0x000000083b2cf0e0 x24: 0x0000000122ab00a0 x25: 0x00000000ffffffff x26: 0x000000012d90bfc8 x27: 0x000000083b03a940 x28: 0x0000000055550483 lr: 0x0000000103b8e020 fp: 0x000000012da0f760 sp: 0x000000012da0f720 -- C level backtrace information ------------------------------------------- ``` -- https://bugs.ruby-lang.org/

2 2