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

[ruby-core:124840] [Ruby Bug#21883] IO::Buffer can be unlocked and freed by another thread during syscall
by hanazuki (Kasumi Hanazuki) 22 Aug '26

22 Aug '26

Issue #21883 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21883: IO::Buffer can be unlocked and freed by another thread during syscall https://bugs.ruby-lang.org/issues/21883 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby # Assume this file is on a very slow device such as NFS. io = File.open('/mnt/slowfs/slow') buf = IO::Buffer.new(100) t1 = Thread.new do buf.locked do sleep 0.5 end buf.free end t2 = Thread.new do buf.read(io) # syscall takes 1 second # When the kernal writes to the memory, buf is already freed, thus use-after-free end t1.join t2.join ``` `io_buffer_blocking_region` skips taking a lock when the buffer is already locked, but this lock may be owned by another thread and can be unlocked during the syscall. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126463] [Ruby Bug#22257] Prepending a module to an already-included module leaves stale super caches
by eightbitraptor (Matt V-H) 21 Aug '26

21 Aug '26

Issue #22257 has been updated by eightbitraptor (Matt V-H). I've created Backport patches [for 4.0](https://github.com/ruby/ruby/pull/18422) and [for 3.4](https://github.com/ruby/ruby/pull/18423) ---------------------------------------- Bug #22257: Prepending a module to an already-included module leaves stale super caches https://bugs.ruby-lang.org/issues/22257#change-118614 * Author: eightbitraptor (Matt V-H) * Status: Open * Target version: 4.1 * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a module is prepended to a module that already has includers, super call sites inside the prepended module keep calling the old method entry after the method is redefined. [**Fix implemented in this PR**](https://github.com/ruby/ruby/pull/18421) <pre> module M; def foo; :m; end; end class D; include M; end M.prepend(Module.new { def foo; super; end }) D.new.foo # prime the super call-site cache M.send(:define_method, :foo) { :hooked } p D.new.foo </pre> I found this while working on an unrelated Ractor issue. But this problem manifests itself for Ractors as follows: <pre> Ractor.new {} require 'set' Kernel.send(:define_method, :require) { |f| $hook = f } require 'set' p $hook # => nil, the hook never runs </pre> This is because creating the first Ractor prepends an internal `RactorRequire` wrapper onto Kernel. After the first require primes the cache in the wrapper, redefining Kernel#require silently does nothing. The linked PR fixes this by registering the backfilled iclass in the module's subclasses list, after the includer walk finishes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111678] [Ruby master Feature#19315] Lazy substrings in CRuby
by Eregon (Benoit Daloze) 21 Aug '26

21 Aug '26

Issue #19315 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #19315: Lazy substrings in CRuby https://bugs.ruby-lang.org/issues/19315 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- CRuby should implement lazy substrings, i.e., "abcdef"[1..3] must not copy bytes. Currently CRuby only reuse the char* if the substring is until the end of the buffer. But it should also work wherever the substring starts and ends. Yes, it means RSTRING_PTR() might need to allocate to \0-terminate, so be it, it's worth it. There is already code for this (`SHARABLE_MIDDLE_SUBSTRING`), but it's disabled by default and `RSTRING_PTR()` needs to be changed to deal with this. It seems a good idea to introduce a variant of `RSTRING_PTR` which doesn't guarantee \0-termination, so such callers can then use the existing bytes always without copy. There are countless workarounds for this missing optimization, all not worth and all less readable: * https://bugs.ruby-lang.org/issues/19314 * https://github.com/ruby/net-protocol/pull/14 * Manual lazy substrings which track string + index + length * More but I don't remember all now, feel free to comment or link more urls/tickets. -- https://bugs.ruby-lang.org/

10 51

[ruby-core:126431] [Ruby Bug#22250] Add an only: keyword to Coverage.peek_result
by sferik (Erik Berlin) 21 Aug '26

21 Aug '26

Issue #22250 has been reported by sferik (Erik Berlin). ---------------------------------------- Bug #22250: Add an only: keyword to Coverage.peek_result https://bugs.ruby-lang.org/issues/22250 * Author: sferik (Erik Berlin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I am a maintainer of SimpleCov and working on adding a feature that attributes coverage to individual tests (see https://github.com/simplecov-ruby/simplecov/pull/1277) This feature works by work by diffing `Coverage.peek_result` snapshots around each test. That means thousands of `peek_result` calls per test run, but each call only needs the line counters, since per-test attribution is computed from line execution count deltas. `peek_result` always builds the full result for every measured type. With branch and method coverage enabled, building the branch and method structures dominates the cost, so each snapshot is an order of magnitude more expensive than the lines the caller actually reads. On a real test suite measuring lines, branches, and methods, per-test tracking causes the test suite to run in ~30 seconds vs. ~3 seconds when it's disabled. Nearly all of this additional time is spent in `peek_result`, building results that are immediately discarded. Line-only filtering is significantly cheaper because the line result is a flat array dup, while branch and method results are rebuilt hashes. #### Proposal Allow callers to request only the types they need: ```ruby Coverage.start(lines: true, branches: true, methods: true) Coverage.peek_result(only: :lines) # => {"file.rb" => {lines: [1, 2, nil]}, ...} Coverage.peek_result(only: [:lines, :branches]) # => {"file.rb" => {lines: [1, 2, nil], branches: {...}}, ...} ``` `only:` should accept one of `:lines`, `:oneshot_lines`, `:branches`, or `:methods`, or an Array of them. Each file's hash then contains only the requested keys, and the result construction for the other measured types is skipped entirely (the branch structure walk and the method table iteration never run). Requesting a type that is not being measured should raise a `RuntimeError`, consistent with the existing "coverage measurement is not enabled" error. An unknown type should raise an `ArgumentError`. A patch with tests and documentation is at https://github.com/sferik/ruby-lang/tree/coverage-peek-result-only The change is confined to `ext/coverage/coverage.c`. The existing `coverage_peek_result_i` iteration takes a filter mask (defaulting to `current_mode`, so the unfiltered path is byte-for-byte the current behavior), and `Coverage.result` reuses the same internal function with the full mask. I am happy to open a pull request if this direction is acceptable. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126434] [Ruby Bug#22251] ObjectSpace::WeakMap#size can return a stale value
by Eregon (Benoit Daloze) 20 Aug '26

20 Aug '26

Issue #22251 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22251: ObjectSpace::WeakMap#size can return a stale value https://bugs.ruby-lang.org/issues/22251 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` $ ruby -e 'm = ObjectSpace::WeakMap.new; Thread.new { m[Object.new] = Object.new }.join; GC.start; p m.size; p m.keys; p m.size' 1 [] 0 ``` The first line is 1 but I would expect 0. Interestingly calling `#keys` seems to force an update. If I GC twice then it seems correct: ``` $ ruby -e 'm = ObjectSpace::WeakMap.new; Thread.new { m[Object.new] = Object.new }.join; GC.start; GC.start; p m.size; p m.keys; p m.size' 0 [] 0 ``` Could we decrease size whenever we "remove" an entry? Apologies if that's already known, I searched for an existing issue for this but didn't find anything. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:121627] [Ruby Feature#21264] Extract Date library from Ruby repo in the future
by hsbt (Hiroshi SHIBATA) 20 Aug '26

20 Aug '26

Issue #21264 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- Note: This is not for Ruby 3.5. `Date` and `DateTime` has no primary maintainer in 10+ years. I would like to deprecate `date` via bundled gems for reducing our maintenance time especially @nobu. But `Time.prase` and `Time.strptime` are widely used now. How do we deprecate `date` library? 1. Migrate `Date._strptime`, `Date.strptime` and `Date._parse` to `Time`. The current `Date` is migrated as bundled gems. 2. Migrate `Date` to the bundled gems. `Time.parse` and `Time.strptime` warns if `date` is not found. 3. Keep the current situation 4. ... Does anyone have another idea? -- https://bugs.ruby-lang.org/

5 10

[ruby-core:126443] [Ruby Bug#22252] improve "defined with an un-shareable Proc in a different Ractor" error
by getajobmike (Mike Perham) 19 Aug '26

19 Aug '26

Issue #22252 has been reported by getajobmike (Mike Perham). ---------------------------------------- Bug #22252: improve "defined with an un-shareable Proc in a different Ractor" error https://bugs.ruby-lang.org/issues/22252 * Author: getajobmike (Mike Perham) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, I'm trying to make my Ruby more compatible with Ractors. I'm seeing this error message but in an API with many abstractions, it can be difficult to determine the Proc in question. Would it be possible to include the source_location of the Proc to help improve debugging? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126158] [Ruby Bug#22211] Fiber::Scheduler stalls on Ractor::Port.receive
by rkh (Konstantin Haase) 19 Aug '26

19 Aug '26

Issue #22211 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22211: Fiber::Scheduler stalls on Ractor::Port.receive https://bugs.ruby-lang.org/issues/22211 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-24T12:18:38Z master 180b664bd9) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Quickly upfront: This might be a duplicate of #20276, and let me know if the official solution is still to launch a thread for each port so it can block (or add some more complex thread orchestration). Anyway, I think `Ractor::Port#receive` should call `Fiber::Scheduler#block`/`Fiber::Scheduler#unblock` if a scheduler is set (or some other hook), the way that `Thread::Queue` does. Instead, it completely blocks the scheduler. Example to reproduce: ``` ruby Warning[:experimental] = false class Scheduler def initialize @fiber = Fiber.current @blocked = Set.new @ready = Queue.new end def scheduler_close @ready.pop.transfer while @blocked.any? end def block(blocker, timeout = nil) raise NotImplementedError, "block: timeout not supported" if timeout @blocked << Fiber.current @fiber.transfer ensure @blocked.delete(Fiber.current) end def unblock(blocker, fiber) = @ready << fiber def io_write(io, buffer, offset, length) = Thread.new { buffer.write(io, offset, length) }.value def fiber(&) = Fiber.new(blocking: false, &).tap(&:transfer) def respond_to_missing?(...) = true def method_missing(method, ...) = raise NotImplementedError, "#{method}: not implemented" end Fiber.set_scheduler(Scheduler.new) # This would work: # # queue = Queue.new # Fiber.schedule { puts queue.pop } # queue.push "Hello from Queue!" port = Ractor::Port.new Fiber.schedule { puts port.receive } port.send("Hello from Ractor::Port!") # never gets here ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126156] [Ruby Bug#22210] Check if issue #19969 is still reproducible / re-opened in 4.0.x
by saka_omo (Yuki Takei) 18 Aug '26

18 Aug '26

Issue #22210 has been reported by saka_omo (Yuki Takei). ---------------------------------------- Bug #22210: Check if issue #19969 is still reproducible / re-opened in 4.0.x https://bugs.ruby-lang.org/issues/22210 * Author: saka_omo (Yuki Takei) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi team, I am writing to ask if Bug #19969 might still be reproducible in the current version of Ruby. Could you please check if the issue is still present or if a regression has occurred? I ran the reproduction script from #19969 across several Ruby versions on macOS (arm64-darwin), and while Ruby 3.2.4 fixed the high memory consumption (dropping to 29 MiB), Ruby 4.0.5 spikes back up to 2215 MiB. ``` ruby ruby -v -rset -e 's1 = Set.new(10000.times); s2 = Set.new(9999.times); Array.new(10000) { s1 - s2 - [0] }; puts "#{`ps -o rss= -p #{$$}`.to_i / 1024} MiB"' ``` Results across versions: ``` ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [arm64-darwin22] 183 MiB ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] 2364 MiB ruby 3.2.4 (2024-04-23 revision af471c0e01) [arm64-darwin22] 29 MiB ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin24] 2215 MiB ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126198] [Ruby Bug#22217] Segmentation fault when resuming execution with `Coverage.start` and ruby/debug
by yokomaru (Yoko Suzuki) 18 Aug '26

18 Aug '26

Issue #22217 has been reported by yokomaru (Yoko Suzuki). ---------------------------------------- Bug #22217: Segmentation fault when resuming execution with `Coverage.start` and ruby/debug https://bugs.ruby-lang.org/issues/22217 * Author: yokomaru (Yoko Suzuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [arm64-darwin25],ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [x86_64-linux],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Resuming execution from `ruby/debug` while coverage collection is enabled via `Coverage.start` can cause a segmentation fault and crash the Ruby process. The crash is intermittent, but reproduces frequently using the same steps. I confirmed it on both macOS (arm64) and Linux (x86_64) using debug 1.11.1. It reproduced with Ruby 4.0.5, Ruby 4.0.6, and Ruby 4.1.0-dev, but did not reproduce in my limited testing with Ruby 3.4.10 or Ruby 3.3.12. ## Reproduction Code `test.rb` ```ruby require "coverage" Coverage.start require "debug" debugger ``` ## Steps to Reproduce Run: ```console $ ruby test.rb ``` At the debugger prompt, enter: ```text continue ``` The same crash also occurs with `next`, `step`, and `finish`. ## Backtrace Excerpt Both macOS and Linux crash around the Ruby VM event hooks. On macOS (arm64), the C-level backtrace includes: ```text libruby.4.1.dylib(exec_hooks_protected+0xb0) libruby.4.1.dylib(rb_exec_event_hooks+0x7c) libruby.4.1.dylib(vm_trace_hook+0x198) libruby.4.1.dylib(vm_trace+0x24c) ``` On Linux (x86_64), it includes: ```text libruby.so.4.1(exec_hooks_body+0x20) vm_trace.c:453 libruby.so.4.1(exec_hooks_protected+0x10b) vm_trace.c:515 libruby.so.4.1(rb_exec_event_hooks+0x83) vm_trace.c:562 libruby.so.4.1(vm_trace_hook+0x17c) vm_core.h:2376 libruby.so.4.1(vm_trace+0x344) vm_insnhelper.c:7373 ``` I've attached the crash log from the latest version (4.1.0-dev). ---Files-------------------------------- test.rb (62 Bytes) stderr-macos-4.1-dev.log (35.7 KB) stderr-linux-4.1-dev.log (35.4 KB) ruby-2026-07-30-112302.ips (15 KB) -- https://bugs.ruby-lang.org/

3 4