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

[ruby-core:124335] [Ruby Bug#21798] `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled
by unasuke (Yusuke Nakamura) 23 Aug '26

23 Aug '26

Issue #21798 has been reported by unasuke (Yusuke Nakamura). ---------------------------------------- Bug #21798: `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled https://bugs.ruby-lang.org/issues/21798 * Author: unasuke (Yusuke Nakamura) * Status: Open * ruby -v: 4.0.0-preview3 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## How to reproduce ```dockerfile FROM ruby:4.0.0-preview3-trixie WORKDIR /ruby_box_test RUN bundle gem foo --test=minitest WORKDIR /ruby_box_test/foo RUN head -n 10 foo.gemspec # PASS RUN bundle install # PASS RUN RUBY_BOX=1 bundle install RUN sed --in-place \ --expression='2i lib=File.expand_path("../lib", __FILE__)\n$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)' \ foo.gemspec RUN sed --in-place \ --expression='s/require_relative "lib\/foo\/version"/require "foo\/version"/' \ foo.gemspec RUN head -n 10 foo.gemspec # PASS RUN bundle install # FAIL RUN RUBY_BOX=1 bundle install ``` This script fails. ``` /usr/local/bin/ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. [!] There was an error while loading `foo.gemspec`: cannot load such file -- foo/version. Bundler cannot continue. # from /ruby_box_test/foo/foo.gemspec:5 # ------------------------------------------- # > require "foo/version" # # ------------------------------------------- Error: building at STEP "RUN RUBY_BOX=1 bundle install": while running runtime: exit status 14 ``` Head of the gemspec file is this. ```ruby # frozen_string_literal: true lib=File.expand_path("../lib", __FILE__) $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib) require "foo/version" Gem::Specification.new do |spec| # ..snip.. end ``` # misc I found this behavior when `RUBY_BOX=1 bundle exec rake spec` on `https://github.com/itamae-kitchen/itamae`. -- https://bugs.ruby-lang.org/

2 2

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

23 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: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: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: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