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

[ruby-core:126531] [Ruby Feature#22274] Make `IO::Buffer` no longer experimental.
by ioquatix (Samuel Williams) 20 Sep '26

20 Sep '26

Issue #22274 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- `IO::Buffer` was introduced in Ruby 3.1 by Feature #18020 as an experimental API. It provides an efficient buffer abstraction for fiber scheduler I/O, zero-copy operations, binary protocol implementations, and access from native extensions. Since then, the API has seen several Ruby releases of real-world use and substantial development. Ruby 4.1 now has cohesive semantics for buffer ownership and lifecycle, slicing, locking, string and file mappings, MemoryView integration, and single-transfer I/O operations. I propose making both the Ruby and public C interfaces of `IO::Buffer` non-experimental in Ruby 4.1. This would involve: * Removing the allocation-time experimental warning. * Removing the experimental status from the class documentation. * Removing `RB_IO_BUFFER_EXPERIMENTAL` from the public C header. * Removing warning suppression that is only required because `IO::Buffer` is experimental. * Updating NEWS to describe `IO::Buffer` as stable. `RUBY_IO_BUFFER_VERSION` would remain available for compile-time feature detection as the interface continues to evolve. Before stabilizing the interface, I would particularly appreciate feedback from JRuby and TruffleRuby maintainers. Related work: * Original proposal: https://bugs.ruby-lang.org/issues/18020 * CRuby implementation PR: https://github.com/ruby/ruby/pull/18486 * TruffleRuby implementation: https://github.com/truffleruby/truffleruby/pull/4248 * JRuby implementation: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/Rub… * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/

3 6

[ruby-core:126499] [Ruby Bug#22264] Warning missing from parse.y hash literals
by kddnewton (Kevin Newton) 20 Sep '26

20 Sep '26

Issue #22264 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22264: Warning missing from parse.y hash literals https://bugs.ruby-lang.org/issues/22264 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- $ ruby --parser=parse.y -cve '{**{}, a: 1, **{a: 2}}' ruby 4.1.0dev (2026-04-21T02:07:14Z aot be86d5704f) [arm64-darwin23] Syntax OK $ ruby --parser=parse.y -cve '{a: 1, **{a: 2}}' ruby 4.1.0dev (2026-04-21T02:07:14Z aot be86d5704f) [arm64-darwin23] -e:1: warning: key :a is duplicated and overwritten on line 1 Syntax OK -- https://bugs.ruby-lang.org/

5 4

[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: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:126530] [Ruby Bug#22273] Aliasing doesn't interact well with Module#prepend
by luke-gru (Luke Gruber) 18 Sep '26

18 Sep '26

Issue #22273 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22273: Aliasing doesn't interact well with Module#prepend https://bugs.ruby-lang.org/issues/22273 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, aliasing doesn't interact well with `Module#prepend` in my opinion. ### Example ```ruby module Kernel prepend(Module.new do def require(feature) puts "requiring feature (prepend): #{feature}" super end end) end module Kernel alias original_require require def require(feature) puts "requiring feature (alias): #{feature}" original_require(feature) end end require "set" ``` This produces this behavior: ``` requiring feature (prepend): set requiring feature (alias): set requiring feature (prepend): set ../ruby/test.rb:5:in 'require': super: no superclass method 'require' for main (NoMethodError) ``` I would expect this behavior: ``` requiring feature (prepend): set requiring feature (alias): set # Then, the original require would succeed ``` This has caused issues such as [22263](https://bugs.ruby-lang.org/issues/22263). ### Bug? As far as I know this is intentional behavior introduced in Ruby 2.0 [here](https://bugs.ruby-lang.org/issues/7842). There are even tests and specs that codify this behavior such as `test_prepend_super_in_alias` and `prepend_spec.rb`. Even though it's intentional, I don't believe it's well thought out. I'm interested in hearing arguments for and against the current behavior (with code examples, preferably). -- https://bugs.ruby-lang.org/

6 9

[ruby-core:126537] [Ruby Bug#22276] alias in a module falls back to Object even in classes not inheriting from Object
by shugo (Shugo Maeda) 17 Sep '26

17 Sep '26

Issue #22276 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22276: alias in a module falls back to Object even in classes not inheriting from Object https://bugs.ruby-lang.org/issues/22276 * Author: shugo (Shugo Maeda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-28T07:43:16Z master 69b49ac7ae) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When `alias` (or `alias_method`) is used in a module and the method is not found in the module, `alias` searches the method from `Object`. So a module can alias a method of `Kernel` or `Object`, and the alias works even if the module is later included in a class that does not have `Object` and `Kernel` as ancestors: ```ruby module M alias foo puts public :foo end class X < BasicObject include ::M end X.new.foo("hello") #=> hello ``` `X` does not include `Kernel`, but `X.new.foo` calls `Kernel#puts`. This fallback comes from Ruby 1.8, where `Object` was the root class, so every class that includes a module always had `Object` and `Kernel` as ancestors. Since Ruby 1.9 introduced `BasicObject`, this is no longer true, but the fallback is unchanged. As discussed in #22273, a module should be able to alias only its own methods and its ancestors' methods, and `Object` is not an ancestor of a module. This behavior is intentional in the current implementation. There are tests for it (`test_alias_in_module` in test/ruby/test_alias.rb for #9663, and "accesses a method defined on Object from Kernel" in spec/ruby/core/module/alias_method_spec.rb), and the documentation of `Module#alias_method` has an example `module Mod; alias_method :orig_exit, :exit; end`. So code like `module M; alias orig_to_s to_s; end` exists, and simply raising `NameError` will break it. Possible fixes: 1. Remove the fallback and raise `NameError`. This breaks existing code. 2. Do not resolve the method at alias time. Instead, resolve it at call time from the ancestors of the receiver's class, like ZSUPER methods. Existing code that includes the module in a subclass of `Object` keeps working, and `X.new.foo` above raises `NoMethodError`. 3. Keep the current behavior and document it. I think 2 is the best choice for compatibility. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 17 Sep '26

17 Sep '26

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125919] [Ruby Bug#22174] Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity
by gil.desmarais (Gil Desmarais) 17 Sep '26

17 Sep '26

Issue #22174 has been reported by gil.desmarais (Gil Desmarais). ---------------------------------------- Bug #22174: Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity https://bugs.ruby-lang.org/issues/22174 * Author: gil.desmarais (Gil Desmarais) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Since `Set` was transitioned to a C-level core class in Ruby 4.0, several operations that allocate new sets or partition subsets (`&`, `^`, `collect!`, `flatten`, `classify`, and `divide`) lost the `compare_by_identity` behavior for the receiver set or its subsets. * For `&`, `collect!`, `flatten`, `classify`, and `divide`, the resulting sets/subsets are allocated without propagating the `compare_by_identity` flag (returning `false` for `#compare_by_identity?`). * For `^` (XOR) with a generic `Enumerable`, the returned set has the flag set (via `dup`), but it allocates a temporary set `tmp` to hold the RHS elements without propagating the `compare_by_identity` flag. This causes the RHS elements to be deduplicated incorrectly using value equality instead of identity equality. A pull request has been opened with the fix and tests: https://github.com/ruby/ruby/pull/17633 ### Reproduction ```ruby require 'set' # 1. Intersection & s1 = Set.new.compare_by_identity s2 = Set.new s1 << "a" s2 << "a" puts "Intersection preserves compare_by_identity: #{(s1 & s2).compare_by_identity?}" # Expected: true # Actual: false # 2. XOR ^ (with duplicate objects by value on RHS) s_xor = Set.new.compare_by_identity x1 = +"x" x2 = +"x" result = s_xor ^ [x1, x2] puts "XOR with Enumerable preserves identity comparison: #{result.size == 2}" # Expected: true (size should be 2, because x1 and x2 are distinct objects) # Actual: false (size is 1) # 3. collect! / map! s_collect = Set.new(["a", "b"]).compare_by_identity s_collect.collect! { |x| x } puts "collect! preserves compare_by_identity: #{s_collect.compare_by_identity?}" # Expected: true # Actual: false # 4. flatten s_flat = Set.new([Set.new([1])]).compare_by_identity puts "flatten preserves compare_by_identity: #{s_flat.flatten.compare_by_identity?}" # Expected: true # Actual: false # 5. classify s_classify = Set.new(["a", "b"]).compare_by_identity classified = s_classify.classify { |x| x } puts "classify subsets preserve compare_by_identity: #{classified.values.all?(&:compare_by_identity?)}" # Expected: true # Actual: false # 6. divide s_divide = Set.new(["a", "b"]).compare_by_identity divided = s_divide.divide { |x| x } puts "divide subsets preserve compare_by_identity: #{divided.all?(&:compare_by_identity?)}" # Expected: true # Actual: false -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126449] [Ruby Bug#22254] [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings
by yqtian (Yongqiang Tian) 15 Sep '26

15 Sep '26

Issue #22254 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22254: [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings https://bugs.ruby-lang.org/issues/22254 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-20T02:56:29Z master ed0b427b4b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I found a public `Prism.dump` path that passes a null source and zero length to `memcpy` in Prism's buffer helper. Clang's `nonnull-attribute` sanitizer reports the call because the effective glibc declaration marks the first two `memcpy` arguments as nonnull. I have not observed a crash, output corruption, or an ordinary non-sanitized failure. I am reporting this as a C correctness/toolchain-contract issue, not a security issue. #### Environment ```text x86-64 Ubuntu Clang 18.1.3 Ruby revision: ed0b427b4ba3c776c763d2673070e88372b2096a Relevant sanitizer: -fsanitize=nonnull-attribute Optimization: -O1 ``` I also checked Ruby HEAD `4012a96bf084d035bf582d58c7dafb31f4762ac6` and the corresponding Prism HEAD `3ea210b30108432b8b75b979872f4fa3c23acb7b`; the source site was unchanged. #### Reproduction From a Ruby checkout, create an out-of-tree build with the same flags used in the validation: ```sh ./autogen.sh mkdir build-ubsan cd build-ubsan ../configure \ CC=clang-18 \ CXX=clang++-18 \ CFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ CXXFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ LDFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all" \ optflags="-O1" \ debugflags="-g" \ --disable-install-doc \ --with-baseruby=/usr/bin/ruby make -j4 UBSAN_OPTIONS=print_stacktrace=0:halt_on_error=0:report_error_type=1 \ ruby ../tool/runruby.rb -- -rprism -e 'Prism.dump("//")' ``` Clang reports: ```text prism/buffer.c:86:40: runtime error: null pointer passed as argument 2, which is declared to never be null ``` Other reproducing inputs include `%r{}`, `//im`, and an empty quoted symbol. Nonempty regexps and symbols, an ordinary empty string, and `%q[]` were clean controls. #### Cause Some Prism node fields use a null-backed empty string representation. `pm_serialize_string` passes the source and zero length through `pm_buffer_append_bytes` to: ```c static PRISM_INLINE void pm_buffer_append(pm_buffer_t *buffer, const void *source, size_t length) { size_t cursor = buffer->length; if (pm_buffer_append_length(buffer, length)) { memcpy(buffer->value + cursor, source, length); } } ``` A sink-side repair is: ```c if (pm_buffer_append_length(buffer, length)) { if (length > 0) { memcpy(buffer->value + cursor, source, length); } } ``` Another possibility is to skip `pm_buffer_append_bytes` when `length == 0` in the serialization template, preserving a stricter buffer-helper invariant. Should the buffer append helpers define a zero-length append as a no-op even when the source is null, or should the serialization caller filter null-backed empty strings? #### Validation I built unmodified and guarded trees with identical Docker/compiler/configure flags. The reproducing `Prism.dump` inputs report in the unmodified build and are clean in both recover and `halt_on_error=1` modes after adding the buffer guard. The unmodified and guarded builds produced byte-identical output for `Prism.dump("//")`: ```text SHA-256 eff5e01617aa527a49aa3b900589b163e4e396807ba252e8440c8a8fbfe047a5 ``` The same native test set passed in both builds, including 1,003 Prism dump tests with 403,474 assertions, plus Prism freeze/parse and Ruby eval/proc/syntax tests. The guarded build produced no `buffer.c` report in this test set. I would be happy to prepare a patch after confirming whether the preferred repair belongs in the common buffer helper or the serialization template. -- https://bugs.ruby-lang.org/

2 2