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

[ruby-core:126480] [Ruby Bug#22259] Arrays sharding a buffer segfault when concatenating with each other
by chucke (Tiago Cardoso) 20 Sep '26

20 Sep '26

Issue #22259 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22259: Arrays sharding a buffer segfault when concatenating with each other https://bugs.ruby-lang.org/issues/22259 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A succession of crashes was observed on a particular workload from our app, involving recursive set operations, after upgrading it to ruby 4.0.6 . LLM was used to build a reproduction (shared in the description of the PR linked below), after which we used it as a harness to get to the actual culprit and fix it. The crash is due to a particular behaviour of how (btw, TIL, so correct my explanation if necessary) ruby arrays share internal buffers, for optimal memory usage. `Array#dup` creates a separate array object, but may share (under certain conditions, i.e. does not embed) the internal C buffer, where objects are stored, with it. Certain modification operations, like `Array#dup`, don't forcefully "copy on write", and instead bump/dec an index on the shared buffer, as so to determine the slice of the original shared buffer it points to. The issue happens with how other operations work, such as `Array#concat`, which is, internally, under certain conditions, copying the full shared buffer to the destination array buffer, without regards of which slice it is about. This is easily demonstrable by the first reproduction in the PR linked below, where the last `concat` operation adds a "phantom" element to the destination array. that element is, at that point, gibberish, malloc-uninitialized data, which causes the VM to crash, depending on what it does with the address found there. This bug has been there for a while, and can be reproduced (with different faulty outcomes) since ruby 3.3 at least (didn't try further back). PR with fix here: https://github.com/ruby/ruby/pull/18472 -- https://bugs.ruby-lang.org/

5 6

[ruby-core:126502] [Ruby Bug#22265] `Thread#value` can return before the target thread completes after a spurious Fiber scheduler unblock
by ioquatix (Samuel Williams) 20 Sep '26

20 Sep '26

Issue #22265 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22265: `Thread#value` can return before the target thread completes after a spurious Fiber scheduler unblock https://bugs.ruby-lang.org/issues/22265 * Author: ioquatix (Samuel Williams) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Ruby 3.3 and 3.4 can allow an untimed `Thread#join` to return after a spurious Fiber scheduler wakeup, even though the target thread is still alive. Because `Thread#value` relies on `Thread#join`, it can consequently return `nil` before the thread completes. This was encountered in `io-event`, where a stale scheduler unblock could resume a fiber waiting for a worker thread. ## Reproducer ```ruby class Scheduler def initialize @root = Fiber.current @ready = [] @blocking = {} @lock = Thread::Mutex.new end def fiber(&block) fiber = Fiber.new(blocking: false, &block) fiber.transfer fiber end def block(blocker, timeout = nil) fiber = Fiber.current @blocking[fiber] = true @root.transfer ensure @blocking.delete(fiber) end def unblock(blocker, fiber) @lock.synchronize {@ready << fiber} end def kernel_sleep(duration = nil) unblock(:sleep, Fiber.current) @root.transfer true end def io_wait(io, events, duration = nil) raise NotImplementedError end def fiber_interrupt(fiber, exception) fiber.raise(exception) end def run while @blocking.any? || @ready.any? ready = @lock.synchronize do ready, @ready = @ready, [] ready end ready.each do |fiber| fiber.transfer if fiber.alive? end Thread.pass if ready.empty? end end end release = Thread::Queue.new target = Thread.new do release.pop :success end Thread.pass until target.status == "sleep" result = :unset runner = Thread.new do scheduler = Scheduler.new Fiber.set_scheduler(scheduler) joining_fiber = Fiber.schedule do result = target.value end Fiber.schedule do scheduler.unblock(:spurious_wakeup, joining_fiber) sleep(0) release << true end scheduler.run ensure Fiber.set_scheduler(nil) end runner.join target.join puts "ruby #{RUBY_VERSION}: result=#{result.inspect}" abort "Thread#value returned before completion" unless result == :success ``` ## Actual result on Ruby 3.4.4 ```text ruby 3.4.4: result=nil Thread#value returned before completion ``` Tested with: ```text ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin25] ``` ## Expected result An untimed `Thread#join` or `Thread#value` should continue waiting after a spurious wakeup: ```text ruby 3.4.4: result=:success ``` ## Existing fix This is fixed in Ruby 4.0 in PR #13532. The reproducer succeeds with Ruby 4.0.5. - Commit: `f0cf4dce65ba7bf3dc6787e10b88e08b411e2c92` - PR: https://github.com/ruby/ruby/pull/13532 ## Proposed backports Backport PRs have been prepared for both affected maintenance branches: - Ruby 3.3: https://github.com/ruby/ruby/pull/18502 - Ruby 3.4: https://github.com/ruby/ruby/pull/18503 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126790] [Ruby Feature#17593] load_iseq_eval should override the ISeq path
by headius (Charles Nutter) 19 Sep '26

19 Sep '26

Issue #17593 has been updated by headius (Charles Nutter). Seems there new movement on related changes but I wanted to add some thoughts. __FILE__ as syntax rather than method eliminates a bunch of side effect behavior that makes __dir__ troublesome: * It needs access to the caller frame or backtrace to find the filename. * It can only be optimized by JIT in most cases. * It can be overridden, undefined, refined when it should remain constant for the lifetime of a loaded piece of code. A middle ground might be to do what JRuby does: introduce an AST node and/or an instruction for it that knows to check a constant pool that can be specified or patched at load time. That has allowed us to cash various forms of preprocessed code without baking in a specific file path or turning this into a method call. ---------------------------------------- Feature #17593: load_iseq_eval should override the ISeq path https://bugs.ruby-lang.org/issues/17593#change-119095 * Author: byroot (Jean Boussier) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Full context in https://github.com/Shopify/bootsnap/pull/343 Consider the following script ```ruby system('mkdir', '-p', '/tmp/build', '/tmp/app') File.write('/tmp/app/a.rb', 'p ["app/a", __FILE__, __dir__]') File.write('/tmp/app/b.rb', 'p ["app/b", __FILE__, __dir__]') File.write('/tmp/build/a.rb', 'p ["build/a", __FILE__, __dir__]; require_relative "b"') $iseq = RubyVM::InstructionSequence.compile_file('/tmp/build/a.rb') class RubyVM::InstructionSequence def self.load_iseq(feature) if feature == "/tmp/app/a.rb" $iseq end end end require '/tmp/app/a.rb' ``` Current behavior: ```ruby ["build/a", "/tmp/build/a.rb", "/private/tmp/build"] /tmp/build/a.rb:1:in `require_relative': cannot load such file -- /private/tmp/build/b (LoadError) from /tmp/build/a.rb:1:in `<main>' from <internal:/opt/rubies/3.0.0-pshopify2/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/opt/rubies/3.0.0-pshopify2/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from /tmp/iseq_debug.rb:16:in `<main>' ``` Expected behavior ```ruby ["build/a", "/private/tmp/app/a.rb", "/private/tmp/app"] ["app/b", "/private/tmp/app/b.rb", "/private/tmp/app"] ``` ### What's going on? `RubyVM::InstructionSequence` instances have a `pathobj` property that is recorded when the source is parsed, and when the ISeq is later evaled, the VM use that `path` as if you were loading a `.rb` file located at that path. So if that source use constructs such as `require_relative`, `__FILE__`, `__dir__`, etc, they will all happen relative to where the source was located upon compilation, not relative to the source was upon evaluation. ### Why is it a problem? Some deployment strategies first build the application in one location, and then later move it elsewhere. That's for instance the case on the Heroku platform. e.g. the deploy looks like ```bash git clone <repo> /tmp/build_xxxx cd /tmp/build_xxxx rake assets:precompile ... mv /tmp/build_xxxx /app ``` Because of this, all the ISeq cached by bootsnap when the code was in `/tmp/build_xxx` have to be invalidated as soon as the source is moved to `/app`, rendering ISeq caching ineffective, and even detrimental as it causes extra writes to disk without bringing any benefits. ### Solution I believe there are two changes that would be needed. First I think that `load_iseq_eval` should set the `fname` as the top stack location. Either by copying the ISeq instance and change its `pathobj`, or by having a way to pass an optional path to `vm_set_top_stack` that would take precedence. I experimented with [a quick hack that changes the ISeq `pathobj` in place](https://github.com/Shopify/ruby/commit/192f5b477f924243e3f6621383e7a…, and it does solve most of the problem. However even with that quick hack another problem remain, the `__FILE__` still evaluate to the original source location. However `__dir__` works as expected, because it is a method that returns the top_stack location. I think `__FILE__` could be changed to be a method as well. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126744] [Ruby Bug#22326] heap buffer overflow in array.values_at()
by danielchong (Daniel Chong) 19 Sep '26

19 Sep '26

Issue #22326 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22326: heap buffer overflow in array.values_at() https://bugs.ruby-lang.org/issues/22326 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I discovered a heap buffer overflow in array.values_at(). I believe the root issue/potential fix is similar to #22325, but the code paths are distinct. PoC: ``` class bad < Numeric def initialize(v); @v = v; end def val; @v; end def <=>(o); @v <=> (o.is_a?(bad) ? o.val : o); end def to_int; $a.clear; @v; end def to_i; @v; end def coerce(o); [o, @v]; end end $a = (1..3000).to_a $a.values_at(Range.new(bad.new(2900), bad.new(2950))) ``` asan output (truncated): ``` ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 408 ... #3 ary_memcpy0 array.c:354 #4 rb_ary_cat array.c:1417 #5 append_values_at_single array.c:3970 #6 rb_ary_values_at array.c:4096 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126656] [Ruby Feature#22304] Add rb_warn_to_remove_at() for deprecation warnings shown by default
by shugo (Shugo Maeda) 18 Sep '26

18 Sep '26

Issue #22304 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22304: Add rb_warn_to_remove_at() for deprecation warnings shown by default https://bugs.ruby-lang.org/issues/22304 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Deprecations such as #22205 and #22276 are scheduled in phases: a warning shown only when `Warning[:deprecated]` is enabled, then a warning shown by default, then the removal. For the first phase, `rb_warn_deprecated_to_remove_at(X.Y, fmt, suggest, ...)` (#17432) prints "... is deprecated and will be removed in Ruby X.Y", and a RUBY_DEBUG build fails to compile when the version reaches X.Y. For the second phase, there is no equivalent API. A warning with the `:deprecated` category is suppressed by default by definition, so the warning must be emitted with `rb_warn` without a category, and the message and the version check have to be written by hand. I propose to add `rb_warn_to_remove_at(X.Y, fmt, suggest, ...)` to internal/error.h: the same message and compile-time check, emitted with `rb_warn`. The name does not contain "deprecated" because `rb_warn_deprecated*` means a warning gated by `Warning[:deprecated]`. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:126584] [Ruby Feature#22297] Module#method_defined? should have an `include_private` argument
by byroot (Jean Boussier) 18 Sep '26

18 Sep '26

Issue #22297 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22297: Module#method_defined? should have an `include_private` argument https://bugs.ruby-lang.org/issues/22297 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Active Record generate methods during boot time based on the database schema. However before defining every one of these methods it first check if it already exists, regardless of visibility, as to avoid overwriting use defined code. As a result, the following pattern is in a few hot spots: ```ruby if method_defined?(name) || private_method_defined?(name) # ... end ``` On our Rails monolith, `private_method_defined?` account for 1% of boot time, that's not massive, but it could very easily be eliminated if there was a way to check for a method existence regardless of its visibility. ### Proposal Currently `Module#method_defined?` signature is: ```ruby method_defined?(symbol, inherit=true) ``` I think we could make it: ```ruby method_defined?(symbol, inherit=true, include_all=false) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126598] [Ruby Feature#22300] `Ractor.check_isolation`: report Ractor isolation violations as warnings instead of raising
by ufuk (Ufuk Kayserilioglu) 18 Sep '26

18 Sep '26

Issue #22300 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #22300: `Ractor.check_isolation`: report Ractor isolation violations as warnings instead of raising https://bugs.ruby-lang.org/issues/22300 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Target version: 4.1 ---------------------------------------- ## Summary We are proposing a `Ractor.check_isolation { ... }` method which runs the given block in a special non-main Ractor. Inside that Ractor, supported operations that would fail because of Ractor isolation report a `:ractor_isolation` category warning, and then continue, instead of raising an isolation error. The special Ractor that is used to run the `Ractor.check_isolation` block is a real non-main Ractor. For example, `Ractor.main?` returns `false` and `Ractor.current` returns a genuine Ractor with its own default port. This is possible by ensuring that no other Ractor executes Ruby concurrently with this special Ractor. That exclusivity makes the "warn and continue" contract safe. ### Examples A trivial code example: ```ruby class Config @settings = {} # not shareable @values = [] # also not shareable def self.settings = @settings def self.values = @values end # Today: the first violation ends the run. Ractor.new { Config.settings }.value #=> Ractor::RemoteError # whose cause is Ractor::IsolationError: can not # get unshareable values from instance variables of # classes/modules from non-main Ractors # With `check_isolation`: the violation is a warning, and the run continues. Ractor.check_isolation do Config.settings # warning, not exception Config.values # ...and the next one is also reported Ractor.main? #=> false end ``` The next example is a test suite that can collect the supported isolation violations in a single run: ```ruby # test_helper.rb ISOLATION_WARNINGS = Thread::Queue.new Warning.singleton_class.prepend(Module.new do def warn(msg, category: nil) if category == :ractor_isolation && !Thread.current[:capturing_isolation_warning] Thread.current[:capturing_isolation_warning] = true begin ISOLATION_WARNINGS << Ractor.make_shareable(msg) ensure Thread.current[:capturing_isolation_warning] = false end return end super end end) class ActiveSupport::TestCase def run(...) Ractor.check_isolation { super } end end ``` ## 1. Motivation ### 1.1 An isolation error stops the run at the first violation Migrating a large codebase to Ractor-safety is difficult, since running it inside a real Ractor gives only one violation per run, which needs to be made Ractor-safe before you can observe the next violation. A large codebase has thousands, if not tens of thousands of these Ractor isolation violations that need to be identified. Our team at Shopify started an effort to make Rails Ractor-safe earlier this year, and as part of that work we needed the full list of isolation problems and not just the first item. To tackle this problem, we used an agent assisted loop against a scaffolded Rails application which served 165 endpoints inside a Ractor. We directed the agent loop to identify and fix the source of the `Ractor::IsolationError`, and run the loop again, until all endpoints could successfully run. While this approach did end up getting us a list of isolation violations, it proved to be an cumbersome task even with agent assistance. Instead, when we built the original prototype of `Ractor.check_isolation`, our initial run reported 50,995 warnings, of which 353 were unique in a matter of minutes with no agent assistance at all. A later run against Rails `main` reported 58,315 warnings, of which 419 were unique. The same work needs 419 build/fix/rebuild cycles (performed by agents or humans) to collect the same information. ### 1.2 You cannot put an existing test suite inside a real Ractor The obvious alternative to the above is to put a `Ractor.new { ... }` around each test in the test suite of the codebase. This approach, while attractive, does not work on real codebases, for three main reasons: 1. The test code must itself be Ractor-safe. Making the tests safe is often harder than making the application safe. Most test helpers hold mutable global state on purpose. 2. The block of `Ractor.new` must be isolated. It cannot close over the test case, the fixtures or the assertion state. 3. Non-shareable arguments and return values are copied. However, copying is not possible for some objects, for example a `Proc`, and the run aborts. `Ractor.check_isolation` removes all three obstacles. The block is not isolated. Arguments, the return value and outgoing message payloads pass by reference. Moreover, any isolation violation warning reported from the test file sources can easily be discarded as irrelevant. ### 1.3 There is no way to keep a codebase Ractor-safe Given the above point, this is the argument that matters most in the long term, in our opinion. A codebase that is Ractor-safe today will not stay Ractor-safe in the future. As the codebase evolves, one new lazy memoization, or one new unfrozen constant in a dependency, will reintroduce a violation. A normal test suite cannot detect the change, because the test suite does not run in a Ractor (as explain in the previous point). A gem can therefore break its downstream users without any signal, and the failure would only appear in production. `Ractor.check_isolation` turns Ractor safety into a property that CI can measure. A gem or an application can wrap its tests in the block and fails the build when the count of unique warnings increases. In essence, our argument is that this proposal gives the ecosystem two things it does not have today: - a burn-down list, to make a codebase Ractor-safe; - a ratchet, to keep it Ractor-safe. ## 2. Proposal ```ruby Ractor.check_isolation(*args, name: nil) { |*args| ... } # -> the value of the block ``` `Ractor.check_isolation` method: - runs the block in a new, real, and special non-main Ractor; - does not isolate the block, and passes arguments by reference; - reports each supported isolation violation as a `:ractor_isolation` category warning, and continues without raising; - unlike an ordinary Ractor, returns a non-shareable block value without copying it, preserving object identity. The reported violations match the constructs that would have raised a `Ractor::IsolationError` under a normal non-main `Ractor`. They include, but are not limited to: - instance variables and class variables of classes and modules; - constants that hold non-shareable objects; - global variables; - `Ractor.make_shareable`, `Ractor.shareable_proc` and `Ractor.shareable_lambda` failures; - calls to Ractor-unsafe C methods; - `fork` from a non-main Ractor; - defining or undefining finalizers on objects owned by another Ractor; - a call to a method that `define_method` defined with a non-shareable `Proc`; - isolation of the check block when it captures outer variables or uses `yield`. The user suppresses isolation-violation warnings with `Warning[:ractor_isolation] = false` or with `-W:no-ractor_isolation`. The exclusivity of the special Ractor that run the block is a precondition of the method, not a mode that the user should select. The current patch relies on `RUBY_RACTOR_EXCLUSIVE=1` and warns when it is unavailable. However, for the final solution we propose that `Ractor.check_isolation` instead establish exclusivity itself and raise when it cannot. Section 4.3 discusses the implementation constraints regarding this. The exclusive mode mentioned here is not a stop-the-world barrier. A blocking operation still hands the run slot over, so that, for example, work that the block correctly dispatches to the main Ractor completes, and the program does not deadlock. ## 3. Implementation Our current patch is on this branch: https://github.com/Shopify/ruby/compare/master...Shopify:ruby:ractor-check-… The branch exposes the design described here under the name `Ractor.check_isolation`. Main points: - A new warning category, `RB_WARN_CATEGORY_RACTOR_ISOLATION`, registered as `:ractor_isolation`. - A flag on the special `rb_ractor_t`. A helper, `rb_ractor_isolation_violation()`, replaces the raise at many of the covered violation sites. The helper warns when the current Ractor has the flag set, and raises otherwise. - `ractor_create0()` creates and marks the special Ractor. When `rb_thread_create_ractor()` starts it, `thread_create_core()` skips `rb_proc_isolate_bang()` and retains the argument array by reference. `rb_proc_check_isolation_warn()` reports the `Proc`-isolation violations that `Ractor.new` would raise, and leaves the closure intact. - `ractor_prepare_payload()` passes a non-shareable message payload by reference, with a warning, instead of copying it. - The bmethod call paths warn instead of raising for a cross-Ractor call to a method defined with a non-shareable `Proc`. - On builds with M:N scheduling, `ruby_mn_threads_params()` enables it and sets `max_cpu = 1` under `RUBY_RACTOR_EXCLUSIVE=1`. - The first call switches the VM into multi-ractor mode. This switch is one-way today. Two costs with the current patch are worth stating explicitly: 1. The VM keeps the multi-ractor overhead for the rest of the process, and 2. the checks sit on paths that a production process executes. We consider these costs acceptable since this feature is a development and CI tool, and should not be enabled in production mode. ## 4. Open questions We have used this feature for four months on Rails and on two large production applications at Shopify. The following questions come out of that use. We do not have a strong position on most of them. 1. **Is `warn` the right surface?**: `Warning.warn` was the cheapest thing to build, but it may be the weakest part of the design, for the following reasons: - The volume is high. In one Shopify application, the run produced more warning text than the 6 GB memory limit of the CI worker, so it was killed. The consumers want a deduplication by site, not a stream of strings. - A string throws the structure away. The consumers want the class, the variable name, the reference chain and the location as data, rather than parsing whatever information is available from the message. - Re-entrancy is a real hazard. Any code in the handler can itself trigger a violation. We hit an infinite recursion this way, and we also hit a stack overflow because formatting the message called `to_s` on a proxy module. - `Warning.warn` is global process state. A warning that the special Ractor reports is awkward to collect in the caller. The alternatives are a callback, or a reporter object: ```ruby Ractor.check_isolation(on_violation: ->(violation) { ... }) { ... } Ractor.check_isolation(reporter: MyReporter.new) { ... } ``` A `violation` object can carry the class, the name, the kind, the reference chain and the backtrace. The warning category can stay as the default when the caller gives no callback. 2. **Should the checks be a build-time option?** The checks add work to hot paths. An alternative is to compile them only into a build that configures them, in the same way as `RGENGC_CHECK_MODE`. This trades convenience for speed. We do not know which side upstream prefers, but considering that so few Ruby developers know how to build a special version of Ruby, we think this will stop the widespread adoption of the feature. 3. **How does the method establish exclusivity?** The current patch reads a boot flag, `RUBY_RACTOR_EXCLUSIVE=1`, and warns once when the flag is absent. We do not propose that as the interface for the final state. The constraint for why we have the boot flag is technical and we welcome suggestions to removing it. Two mechanisms in `thread_sched.c` decide the outcome: - `vm->ractor.sched.max_cpu` caps the number of shared native threads. The VM reads it when an NT rejoins the pool, so lowering it at runtime does not retire the NTs that already exist. They retire lazily, and `SNT_KEEP_MINIMUM` keeps some of them alive. - `enable_mn_threads` decides how each thread gets a native thread, and the VM reads it when the thread is created. A thread created while the flag was off holds a dedicated native thread. A dedicated NT is its own OS thread and ignores `max_cpu` completely. Together these mean that a switch at the time of the call cannot cover the threads that the process already has, but it can cover a process with no other living threads. We therefore propose: - `Ractor.check_isolation` switches the VM to a single run slot when it is the only living thread in the process, and runs the block; - otherwise it raises, and names the threads that prevent the guarantee. This removes the flag from the common case, and it turns a silent unsound result into an error. Ideally, we would like to find a solution where we can create a special exclusive Ractor regardless of the state of the VM, but need more guidance on how to achieve that. 4. **How does this interact with Feature #22226?** Class and module ownership changes which accesses are violations. The checker must follow the same rule, and we are prepared to improve the proposal to obey this invariant as well. Moreove, the special Ractor should also behave like how a real Ractor would with respect to the ownership of the classes/modules that the block creates. Otherwise, it would report fewer violations than a production worker would hit. 5. **Is passing by reference acceptable in a public API?** The block, the arguments, the return value and outgoing message payloads all bypass the isolation rules. This is sound because the special Ractor runs exclusively, so it is not a safety concern. 6. **What are the semantics for nested calls and for threads?** In our current patch, a nested call creates another special Ractor and resumes the calling Ractor when it returns. A thread that the block creates belongs to the special Ractor and therefore observes the check and only raises warnings. On the other hand, a Ractor created with `Ractor.new` does not inherit the check, and raises `Ractor::IsolationError` for isolation errors. We think this behaviour is right, but it should be specified. 7. **Should the VM deduplicate?** Most consumers want unique violations per source location, and they build that themselves. A `Set` of sites in the VM would cut the volume by two orders of magnitude. On the other hand, it might also hide a violation that occurs on a second path through the same line, and would make it hard to collect how many times each unique violation is seen. ## 5. Related issues - #22226: Ractor: class/module ownership. Changes which accesses are violations. - #22252: improve the "defined with an un-shareable Proc in a different Ractor" error. This feature downgrades the same check to a warning. - [ruby/ruby#15983](https://github.com/ruby/ruby/pull/15983): the reference chain in `Ractor::IsolationError#detailed_message`. Adding the same chain to the warnings would make a violation more actionable. ## 6. Acknowledgements Different parts of this patch were built by Ufuk Kayserilioglu, Edouard Chin and Hartley McGuire, using LLM assistance. @ko1 provided guidance on our original approach which was using a special Thread instead of a special Ractor. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126779] [Ruby Bug#22335] Stack corruption with >31 keyword args and refined Integer#==
by eapache_opslevel (Evan Huus) 18 Sep '26

18 Sep '26

Issue #22335 has been reported by eapache_opslevel (Evan Huus). ---------------------------------------- Bug #22335: Stack corruption with >31 keyword args and refined Integer#== https://bugs.ruby-lang.org/issues/22335 * Author: eapache_opslevel (Evan Huus) * Status: Open * ruby -v: 4.0.7 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is a messy one that originally surfaced as a flaky test in our Rails app, and required a lot of AI-assisted debugging to track down. This bug appears in the latest 4.0.7, though all of the original investigation was done against 3.3.11. If you have: - a method that takes only keyword args - has >31 keyword args - has a call-time-evaluated default value (e.g. `{}`) at argument index >31 - running in a Ruby process that has refined `Integer#==` at any point Then you get inconsistent stack corruption depending on your process's hash salt. The mechanism is nasty: - In a method with only keyword args, `vm_call_iseq_setup_kwparm_kwarg()` call `args_setup_kw_parameters()` with `klocals = argv + kw_param->bits_start - kw_param->num`, i.e. **above `cfp->sp`**, without first extending `cfp->sp` over those locals - `args_setup_kw_parameters()` uses a full hash, keyed by integer, for arguments beyond index 31 - When `args_setup_kw_parameters()` sets a key in that hash, and that key collides with another (not uncommon for a tiny hash, but still salt-dependent), it triggers an integer comparison - The refinement on `Integer#==` prevents that comparison from taking the fast path and turns it into a real C frame - Which gets pushed onto the stack, when the stack pointer hasn't been extended - Thus overwriting the other args and producing garbage The net effect is that the called method sees garbage values for the overwritten arguments. I've attached a reproducing script, which is unfortunately complex, as it needs to do some work to intentionally hit the correct hash collision depending on the process's salt. A simpler static version doesn't reproduce reliably enough to be useful. Even this version will occasionally get a hash salt with no collisions and fail to reproduce, though that seems pretty rare on my machine. ---Files-------------------------------- repro.rb (1.51 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126187] [Ruby Bug#22216] Regexp backref and IO lastline are incompatible with Ractor
by headius (Charles Nutter) 18 Sep '26

18 Sep '26

Issue #22216 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #22216: Regexp backref and IO lastline are incompatible with Ractor https://bugs.ruby-lang.org/issues/22216 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem Several Regexp-matching methods currently write (and sometimes read) the implicit "backref" `$~` variable in the local frame (and related variables like `$'`). Several IO methods read or write the "last line" `$_` variable in the same way. In both cases, the result is a mutable object, which makes these variables already problematic for ractors. Making matters worse, the frame might be shared if a proc is captured and used across threads or ractors, and there's no static way to inspect a piece of code to know if it expects to read or write these variables. Where procs can be rejected by a proc for accessing captured state, there's no such check possible for these variables. All of these facts make the backref and lastline variables fundamentally incompatible with Ractor. ## Possible remedies A wholesale removal of these variables would solve the problem, but there's a lot of code that depends on them... much of that code without even realizing it, since they might not access the variables directly. In some cases, the dependencies are internal and part of the behavior of core methods. Hard errors when using methods that read or write these variables would avoid introducing threading problems into a Ractor, but would also break a large number of commonly-used methods. There have been experiments to make these variables both frame and thread-local, but they have never been made standard. Updates to backref and lastline are visible across threads and already can lead to concurrency issues even on CRuby. Deprecating the implicit behavior and making it opt-in (or opt-out?), perhaps with keyword arguments or file pragmas, might be a halfway measure. It would probably not be an easy transition. I don't know the right path forward, but I believe this issue needs to be discussed. ## JRuby perspective We continue to mimic CRuby behavior, which has led to our users occasionally running into issues when a proc accesses these variables across threads. Our recommendation: "don't do that". We also have had our frustrations optimizing around these variables, since they implicitly require access across calls. Because we cannot statically detect when they will be used, we essentially treat all method names that might *potentially* access them as deopt triggers. It's not ideal. I'd like to hear ideas for how to make these variables less "magic", less implicit and easier to deal with across calls (and across threads/ractors). -- https://bugs.ruby-lang.org/

7 27

[ruby-core:126675] [Ruby Feature#22309] Allow super in a module method to work if method was called by refinement method super
by jeremyevans0 (Jeremy Evans) 18 Sep '26

18 Sep '26

Issue #22309 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22309: Allow super in a module method to work if method was called by refinement method super https://bugs.ruby-lang.org/issues/22309 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby started allowing refinements of modules in 2.4. However, there was one limitation, which is that while the refinement method could call `super` to call the module method, the module method could not call `super`, because it did not have enough information to determine the appropriate ancestor. This limitation was known at the time and was accepted when module refinements were accepted in #12534. As discussed in #22071, `super` wasn't actually prohibited in the module method, it just used the incorrect method lookup, looking for a super method in `BasicObject`. After discussion in #22071, I fixed this to use an explicit exception for this case, so an error was was raised for it. While that addressed the incorrect super method lookup issue, it was an unsatisfying conclusion. I kept thinking about ways to actually fix the issue. My initial idea was to use a separate `T_ICLASS` for the module being refined in every class ancestry chain where it could be called via refinement `super`. However, that approach would result in a large amount of complexity, as well as potentially significant additional memory. I am instead proposing an alternative approach which relies on the fact that when we call `super` in the module method, we know that the current method is a module method, and that the previous method in the call stack is a refinement method. We can walk up the call stack to find the refinement method, look at the previous method calling that to determine the class to use for the super lookup. Note that the previous method may use a different receiver/method, in which case we start with the receiver's class. There are cases where we need to do this multiple times, if there are multiple refinements or multiple modules being refined that have already called super to reach this point. I'm not sure this alternative approach works in all cases, but I have gotten it to work every case I've tried: * Module and refinement appears multiple times in the ancestor chain * `super` calls both directly in method as well as in nested blocks in method * Both refinement method and module method are bmethods * Refinement refines multiple modules and both modules are involved in the same super call chain * Multiple refinements of the same module method * Use of ZSUPER aliases in the super call chain * The `super` call in the module method is not found, and `NoMethodError` is raised correctly We want the behavior of module refinement `super` to be consistent, so in addition to fixing `super` itself, we also need to fix `defined?(super)` as well as `Method#super_method` and `UnboundMethod#super_method`. `defined?(super)` is fixed by sharing the lookup that `super` now uses. However, `Method#super_method` and `UnboundMethod#super_method` require a different approach. Thankfully, `struct METHOD` already has a member named `iclass` that is used to implement `#super_method`. So we just need to make adjustments to the setting of the `iclass` member for `#super_method` to work. Simple example: ```ruby module M def m = [:M, *super] end class C prepend M def m = :C end module R refine M do def m = [:R, *super] end end using R C.new.m # => [:R, :M, :C] ``` I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/18797 -- https://bugs.ruby-lang.org/

2 5