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

[ruby-core:126083] [Ruby Bug#22195] `IO::Buffer` read after free silently returns empty data instead of raising
by himura467 (Akito Shitara) 22 Aug '26

22 Aug '26

Issue #22195 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22195: `IO::Buffer` read after free silently returns empty data instead of raising https://bugs.ruby-lang.org/issues/22195 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading from an `IO::Buffer` after calling `#free` does not raise. It behaves like an empty buffer, and `#valid?` still returns `true`: ```ruby buffer = IO::Buffer.for("Hello World") buffer.free buffer.valid? # => true buffer.get_string # => "" (no error) ``` ## Why this looks like an unintended regression Originally (https://github.com/ruby/ruby/commit/e30920354f, Ruby 3.1–3.3), accessing a freed buffer raised `IO::Buffer::AllocationError` ("The buffer is not allocated!"). https://github.com/ruby/ruby/commit/c5cf4d4e12 made zero-length buffer operations succeed instead of raising, for [Bug #19542] and [Bug #18805]. Since a freed buffer also has `base == NULL, size == 0`, it was caught in the same code path and stopped raising too. Neither ticket mentions freed buffers, so this appears to be an accidental side effect rather than a decision. Note that the rdoc of `#free` still promises that access after free raises. ## Proposal How about marking a buffer as invalidated when it is explicitly freed (`#free` / `rb_io_buffer_free`), so that: * `#valid?` returns `false`. * Any byte access raises `IO::Buffer::InvalidatedError` or `IO::Buffer::AllocationError`. * `#resize` re-allocates and clears the mark, as `#free`'s rdoc promises ("You can resize a freed buffer to re-allocate it"). * The zero-length buffer semantics from https://github.com/ruby/ruby/pull/9532 are preserved: `IO::Buffer.new(0)`, `resize(0)` and zero-length slices remain valid and readable. I'm not sure which exception class is preferable: `IO::Buffer::InvalidatedError` is consistent with how invalidated slices already behave and with `#valid?` returning `false`, while `IO::Buffer::AllocationError` restores the pre-3.4 behavior. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:125811] [Ruby Bug#22125] IO::Buffer triggers use-after-free when it's freed/resized during enumeration
by hanazuki (Kasumi Hanazuki) 22 Aug '26

22 Aug '26

Issue #22125 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22125: IO::Buffer triggers use-after-free when it's freed/resized during enumeration https://bugs.ruby-lang.org/issues/22125 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T09:56:24Z master 55945e5c98) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The block passed to `IO::Buffer#each` can free or resize the receiver (or its parent buffer when the reciver is a slice), which invalidates the memory region being iterated. The next iteration causes use-after-free. repro: ``` ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.resize(20) }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b.free }' # No use-after-free but I think those should be errors too ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b1.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.transfer }' ``` same for `#each_byte`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121507] [Ruby Bug#21212] IO::Buffer can be freed while its slice is locked
by hanazuki (Kasumi Hanazuki) 22 Aug '26

22 Aug '26

Issue #21212 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21212: IO::Buffer can be freed while its slice is locked https://bugs.ruby-lang.org/issues/21212 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.5.0dev (2025-04-01T16:11:01Z master 30e5e7c005) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby buffer = IO::Buffer.new(100) slice = buffer.slice buffer.locked do buffer.free rescue p $! #=> IO::Buffer::LockedError (expected) end slice.locked do p slice.locked? #=> true (expected) p buffer.locked? #=> false (what should this be?) slice.free rescue p $! #=> IO::Buffer::LockedError (expected) buffer.free # Should we allow this? slice.set_value(:U8, 0, 42) # raises IO::Buffer::InvalidatedError (surprising!) end ``` -- https://bugs.ruby-lang.org/

3 3

[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