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

[ruby-core:125938] [Ruby Feature#22182] Optimize method chains by destructively updating intermediate objects
by mame (Yusuke Endoh) 20 Jul '26

20 Jul '26

Issue #22182 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #22182: Optimize method chains by destructively updating intermediate objects https://bugs.ruby-lang.org/issues/22182 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- This is an experimental optimization idea that speeds up typical method chains by destructively updating their intermediate objects. Intuitively, it works like this: * `str.strip.upcase` runs like `str.strip.upcase!` * `ary.map {}.select {}` runs like `ary.map {}.select! {}` * `"foo" + str + str` runs like `"foo" << str << str` As a bonus: * `foo(**opts.merge(default))` passes the merged hash to the callee as-is, without `Hash#dup` ## Microbenchmarks 1-second measurement windows, average of 5 alternating rounds (µs/call). |Code|Before|After|Speedup|Setup| |--|--|--|--|--| |`str + str + str`| 0.127 µs | 0.088 µs | 1.44x |`str = "x" * 100`| |`ary + ary + ary`| 0.645 µs | 0.304 µs | 2.12x |`ary = (0..99).to_a`| |`"foo" + str`| 0.083 µs | 0.056 µs | 1.50x |`str = "bar"`| |`ary.map { it+1 }.select { it.even? }`| 6.86 µs | 6.64 µs | 1.03x |`ary = (0..99).to_a`| |`str.strip.upcase`| 0.099 µs | 0.090 µs | 1.10x |`str = " foo "`| |`"#{a}#{b}".strip`| 0.110 µs | 0.103 µs | 1.07x |`a = "abcdefgh"; b = "ijklmnop"`| |`ary.uniq.sort.reverse`| 38.7 µs | 36.4 µs | 1.06x |`ary = (0..999).map { it % 500 }.shuffle`| |`foo(**opts.merge(default))`| 0.557 µs | 0.489 µs | 1.14x |`def foo(**kw) = kw; opts = (0...10).to_h { [:"o#{it}", it] }; default = (0...10).to_h { [:"d#{it}", it] }`| Allocations go down as well (e.g. `str + str + str` goes from 2 objects to 1). ## How it works In one sentence: a limited form of escape analysis, specialized for method chains. We introduce flags (`STR_FRESH` / `ARY_FRESH` / `HASH_FRESH`) for `String` / `Array` / `Hash` objects whose only reference is guaranteed to be a single value-stack slot. Since no one else can observe a flagged object, the next operation may reuse it destructively. A few instructions are added. The typical one is `opt_plus_fresh`. For example, `str1 + str2 + str3` compiles and runs as: ``` getlocal str1 getlocal str2 opt_plus_fresh # concatenate into a new String and set STR_FRESH on it; since it will # almost certainly be appended to, allocate with extra (2x) capacity getlocal str3 opt_plus # if the receiver has STR_FRESH, append in place instead of # allocating a new object ``` `ary.map {}.select {}` compiles and runs as: ``` getlocal ary send :map (callinfo: VM_CALL_FRESH_PROD) # if the method cache resolved to the built-in # Array#map, set ARY_FRESH on the resulting array send :select (callinfo: VM_CALL_FRESH_CONS) # if the method cache resolved to the built-in # Array#select and the receiver has ARY_FRESH, # call the select!-style destructive implementation ``` There are also a few instructions that create objects with the FRESH flag set (`newarray_fresh`, `duparray_fresh`, `dupstring_fresh`, `concatstrings_fresh`). These make `"foo" + str`, `[1, 2, 3].sort` and `"#{a}#{b}".strip` destructive as well. ## PoC implementation Implemented by Claude Code (Fable 5). Still a proof of concept. https://github.com/ruby/ruby/pull/17685 9 commits: 1. Add the STR_FRESH / ARY_FRESH / HASH_FRESH object flags (+ clearing in ObjectSpace.each_object) 2. Preparatory refactoring: extract str_enc_buf_new0() from str_enc_new() 3. String#+ chains: reuse the intermediate in place (opt_plus_fresh / dupstring_fresh) 4. Array#+ chains: same 5. Built-in String chains: apply destructive counterparts to fresh receivers (strip.downcase, sub with arguments, interpolated heads, ...) — also introduces the common machinery (unconditional callinfo bits + fresh_producer/fresh_consumer method entry bits + the table) 6. Built-in Array chains (map/select/... + take/drop + split/to_a/flat_map/sort_by/set-operation producers + literal heads like `[3,1,2].sort`) 7. Built-in Hash chains (merge/transform_values/select/reject/compact) 8. Hand over fresh splat / kw-splat operands (`f(*xs.map {})` / `foo(**opts.merge(default))` skip the defensive copy — a runtime generalization of the existing `VM_CALL_ARGS_SPLAT_MUT` / `KW_SPLAT_MUT`) 9. Minimal YJIT support (+ chains are also fused in JITed code; built-in send chains stay inactive but sound. Same for ZJIT.) ## Implementation notes This optimization needs delicate care so that FRESH-flagged objects never leak into ordinary code. Optimization is therefore applied only in very restricted situations: * Only chains that use known method names (`map`, `select`, ...) are optimized. (This prevents a leak through e.g. `ary.map {}.tap { it }`.) * Optimization applies only while none of those `String`/`Array`/`Hash` methods are redefined. * `ObjectSpace.each_object` clears the FRESH flag of every object it yields. * A receiver passed to `method_missing` has its FRESH flag cleared. * In case a target method is redefined in the middle of a chain, a consumer site whose call cache was invalidated clears the receiver's FRESH flag. There may be other paths through which a FRESH object can leak; please let me know if you spot one. In principle this should almost never slow down ordinary code: the only cost is one FRESH flag test in `opt_plus` for String and Array. Indeed, a plain `str + str` (not optimized) measured 0.071 µs both before and after the patch (1.00x). Fixnum `+`, standalone `merge` / `sort`, `foo(**h)` etc. all measured 0.98-1.03x. ## Limitations String has no spare flag bits, so the PoC reuses STR_PRECOMPUTED_HASH == STR_FRESH: the bit is read as STR_PRECOMPUTED_HASH on frozen strings and as STR_FRESH on unfrozen ones. Under `frozen-string-literal: true`, `"foo" + str` is currently not optimized (perhaps improvable?). YJIT support is provisional. `+` chains are fused in JITed code too, but the destructive reuse in built-in send chains only happens in interpreted execution. In particular, with a JIT enabled, Array chains are disabled entirely (YJIT redefines `Array#map` / `Array#select` in Ruby, which trips the redefinition detection, unfortunate). Only prism is supported for now (parse.y is not). There are probably other things I have missed. ## Discussion Ordinary code does not get slower, and some code skips intermediate allocations entirely, so I believe this is essentially all upside. That said, keeping FRESH objects from leaking makes this a fairly intricate and delicate optimization, so I would like to hear from VM and JIT developers. Whether this shows up in "macro" benchmarks is questionable: code like `"foo" + str + str + str`, where the optimization shines, has traditionally been avoided, and the intermediate objects it eliminates would almost certainly have been collected by minor GC anyway, so they rarely amount to real GC pressure. Still, having common idioms like `"foo" + str` or `ary.uniq.sort.reverse` get 1.1-1.5x faster is a nice thing, and reducing the general uneasiness about "this creates an intermediate array" seems worthwhile, IMO. What do you think? -- https://bugs.ruby-lang.org/

4 15

[ruby-core:126077] [Ruby Bug#22194] File.realpath and File.realdirpath handle differently path encoding incompatible to a filesystem's one
by andrykonchin (Andrew Konchin) 20 Jul '26

20 Jul '26

Issue #22194 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #22194: File.realpath and File.realdirpath handle differently path encoding incompatible to a filesystem's one https://bugs.ruby-lang.org/issues/22194 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Both `realpath` and `realdirpath` methods accept a `path` parameter and try to return result in the `path`'s encoding. `realpath`: ```ruby File.realpath(".rubocop.yml").encoding # => #<Encoding:UTF-8> File.realpath(".rubocop.yml".encode("US-ASCII")).encoding # => #<Encoding:US-ASCII> ``` `realdirpath`: ```ruby File.realdirpath("src").encoding # => #<Encoding:UTF-8> File.realdirpath("src".encode("US-ASCII")).encoding # => #<Encoding:US-ASCII> ``` But it's possible that `path`'s encoding isn't compatible to the filesystem's one (that's is common to be UTF-8 on Linux and macOS), that's converting from the filesystem's encoding to `path`'s encoding fails. In this case `realpath` and `realdirpath` behaves differently - `realpath` just "forces" encoding to `path`'s one (and as fallback to filesystem's and then to binary if a string becomes broken) and `realdirpath` just returns a string in the filesystem's encoding. `realpath`: ```ruby File.realpath(".".encode(Encoding::ISO_8859_1), "test_dir_🦊").encoding # => #<Encoding:ISO-8859-1> ``` `realdirpath`: ```ruby File.realdirpath(".".encode(Encoding::ISO_8859_1), "test_dir_🦊").encoding # => #<Encoding:UTF-8> ``` It makes sense for the methods to handle this edge case consistently. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115018] [Ruby master Bug#19922] ObjectSpace.dump_all in multiple threads in parallel causes SEGV
by wanabe (_ wanabe) 20 Jul '26

20 Jul '26

Issue #19922 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #19922: ObjectSpace.dump_all in multiple threads in parallel causes SEGV https://bugs.ruby-lang.org/issues/19922 * Author: wanabe (_ wanabe) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `ObjectSpace.dump_all` in multiple threads in parallel causes SEGV. The reproduce code is here: ``` $ ruby -robjspace -e 'def dump; 10.times { ObjectSpace.dump_all } end; Thread.new { dump }; dump' /home/wanabe/.rbenv/versions/master/lib/ruby/3.3.0+0/objspace.rb:100: [BUG] Segmentation fault at 0x0000000000000000 (snip) ``` I attached the full log. I assumed that: - Thread1 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd1 - calls `dump_flush()` - changes current thread due to IO - Thread2 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd2 - calls `dump_flush()` - changes current thread due to IO - Thread1 - gets unexpected `GET_RACTOR()->mfd`: mfd2 ---Files-------------------------------- bug.log (23.1 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:126115] [Ruby Bug#22203] Coverage (eval: true): branch entries for re-eval'd code are nondeterministically duplicated
by sferik (Erik Berlin) 20 Jul '26

20 Jul '26

Issue #22203 has been reported by sferik (Erik Berlin). ---------------------------------------- Bug #22203: Coverage (eval: true): branch entries for re-eval'd code are nondeterministically duplicated https://bugs.ruby-lang.org/issues/22203 * Author: sferik (Erik Berlin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When the same code is eval'd more than once against the same file path under `Coverage.start(branches: true, eval: true)`, the branch section of `Coverage.result` sometimes contains one condition entry with accumulated arm counts, and sometimes contains multiple condition entries at identical source coordinates (differing only in their id element), each carrying only the executions of one compile. Which of the two shapes you get varies from run to run of the same program and is influenced by GC. On Ruby 3.2 through 3.4 the entries were almost always merged. On Ruby 4.0 they are almost always duplicated, so programs that rely on the long-standing de facto behavior changed silently. This is related to but distinct from #19857, which asked for line counts to accumulate across evals and was rejected as a design decision. My concern is that the shape of the branch result is nondeterministic and that lines and branches disagree with each other in a single run. #### Reproduction ```ruby require "coverage" Coverage.start(lines: true, branches: true, eval: true) src = "if $flag\n :a\nelse\n :b\nend\n" $flag = true; eval(src, binding, "fake.rb", 1) $flag = false; eval(src, binding, "fake.rb", 1) result = Coverage.result["fake.rb"] puts "conditions: #{result[:branches].size}" result[:branches].each { |cond, arms| puts " #{cond.inspect} => #{arms.values.inspect}" } puts "lines: #{result[:lines].inspect}" ``` Adding `GC.start` between the two evals makes the duplication reproduce on every run on 4.0.6. I'd expect that either the second compile reuses the existing branch entries for that path, so there is one condition whose arm counts cover both evals (the behavior Ruby 3.2 through 3.4 exhibit) or every compile appends fresh entries, always. I can work with either semantics, but can’t rely on a structure that depends on GC timing. In the current state, SimpleCov and similar tools can’t distinguish one branch, observed twice from two branches, each half-observed. Here are examples of the two different shapes I'm seeing across runs of identical code: Merged (one condition, arms accumulated across both evals): ``` conditions: 1 [:if, 0, 1, 0, 5, 3] => [1, 1] ``` Duplicated (two conditions at identical coordinates, complementary counts): ``` conditions: 2 [:if, 0, 1, 0, 5, 3] => [1, 0] [:if, 3, 1, 0, 5, 3] => [0, 1] ``` Observed rates for 10 runs each, "gc" meaning `GC.start` inserted between the two evals: ``` ruby 3.2.11: plain 0/10 duplicated, gc 1/10 duplicated ruby 3.3.12: plain 0/10 duplicated, gc 0/10 duplicated ruby 3.4.10: plain 0/10 duplicated, gc 1/10 duplicated ruby 4.0.6: plain 9/10 duplicated, gc 10/10 duplicated ``` So the failure to reuse existing entries has existed at low frequency since eval coverage was introduced (it can be provoked with GC pressure on 3.2 through 3.4), and Ruby 4.0 inverted the common case. Additionally, lines and branches disagree within a single run. Eval'ing the same code twice down the same arm gives: ``` lines: [1, 1, nil, 0, nil] # line counts reflect only the last compile (per #19857 design) branches: [:then] => 2 # branch counts accumulated across both compiles ``` The branch counter says the arm ran twice while line coverage says its line ran once. Whichever semantics is intended, the two criteria should agree. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125892] [Ruby Feature#22138] Add `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag for `rb_nogvl`.
by ioquatix (Samuel Williams) 20 Jul '26

20 Jul '26

Issue #22138 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22138: Add `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag for `rb_nogvl`. https://bugs.ruby-lang.org/issues/22138 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- Add a new flag, `RB_NOGVL_PENDING_INTERRUPT_FAIL`, to `rb_nogvl()`. When set, `rb_nogvl()` does not enter the blocking region (does not call the supplied function) if the current thread has *pending interrupts* — including interrupts that are currently masked by `Thread.handle_interrupt`. In that case it returns `0` without calling the function, with `errno == 0` — the same as the existing `RB_NOGVL_INTR_FAIL` skip path (the function was never called). This gives selector / event-loop extensions a reliable way to detect that a thread has work to do (a pending interrupt) *before* committing to a potentially unbounded native wait, so they can unwind and let Ruby process the interrupt instead of hanging. ## Background and motivation `rb_nogvl()` already supports a "fail before blocking" mode via `RB_NOGVL_INTR_FAIL` (`0x1`). With that flag, if the VM has been interrupted (`RUBY_VM_INTERRUPTED_ANY`) before the blocking region is entered, the function is skipped and `rb_nogvl()` returns `0`. This is used by `rb_thread_call_without_gvl2()`. However, `RB_NOGVL_INTR_FAIL` only reacts to *deliverable* interrupts. It does not account for interrupts that the current thread has deliberately deferred via `Thread.handle_interrupt`. There is an important class of bugs where: 1. A thread has a pending interrupt (e.g. a `Thread#raise`, a timeout, a shutdown/termination request). 2. That interrupt is masked by an enclosing `Thread.handle_interrupt(... => :never)` / `:on_blocking` region — typical in schedulers, supervisors and connection pools that want to control exactly where interrupts are delivered. 3. The thread is about to enter a native wait (e.g. `kqueue`/`epoll`/`select`, or some other blocking syscall) with the GVL released. 4. Because the interrupt is masked, the existing `RB_NOGVL_INTR_FAIL` check does not trip, the native wait is entered, and — if nothing else wakes it — the wait can block indefinitely. The pending interrupt is never observed. This is not hypothetical: it was hit in production through `async-container` and `io-event`, where a scheduler entering a native selector wait could hang because a pending (masked) interrupt was not noticed before the wait began. A blocking operation that is skipped because the thread has pending work should be treated the same way as an interrupted wait: return immediately without entering the wait, and let the caller unwind so Ruby can process the interrupt. ## Proposal Add the flag: ```c #define RB_NOGVL_PENDING_INTERRUPT_FAIL (0x8) ``` Semantics when the flag is set: - If the current thread has pending interrupts (as reported by the thread's pending-interrupt queue, *including* interrupts masked by `Thread.handle_interrupt`), `rb_nogvl()` does **not** call `func`. It returns `0`. - Otherwise `rb_nogvl()` behaves as usual: it enters the blocking region, calls `func`, and preserves `func`'s resulting `errno`. The check is performed both as an early pre-check (before any of the blocking-region machinery runs) and again inside the blocking-region setup, to close the window between the pre-check and the point where the GVL is released. ## Relationship to existing flags - `RB_NOGVL_INTR_FAIL` (`0x1`) reacts to *deliverable* VM interrupts (`RUBY_VM_INTERRUPTED_ANY`). It does not consider interrupts deferred by `Thread.handle_interrupt`. - `RB_NOGVL_PENDING_INTERRUPT_FAIL` (`0x8`) reacts to *pending* interrupts in the thread's queue, **including masked ones**. This is the key difference: it lets a caller bail out before a native wait even when the interrupt is not currently deliverable, so the caller can unwind to a point where the interrupt can be handled safely. The flags are independent and may be combined with each other and with `RB_NOGVL_UBF_ASYNC_SAFE` / `RB_NOGVL_OFFLOAD_SAFE`. ## Example A common pattern is to have the callback write its result into a struct that is pre-initialised to a sentinel (e.g. `-1`), then report failure once back under the GVL: ```c struct Arguments { int result; }; static void *my_func(void *ptr) { struct Arguments *arguments = ptr; arguments->result = my_syscall(); return NULL; } struct Arguments arguments = {.result = -1}; rb_nogvl(my_func, &arguments, ubf, &arguments, RB_NOGVL_PENDING_INTERRUPT_FAIL); if (arguments.result == -1) { // Either the syscall ran and was interrupted (errno == EINTR), or it was // not run at all because the thread had pending interrupts (errno == 0). rb_sys_fail("my_syscall"); } ``` Note the `errno` caveat for this proposal: on the skip path `errno` is `0`, and `rb_sys_fail()` does not behave well with `errno == 0`. A caller that wants to funnel both cases through `rb_sys_fail()` should normalise it: ```c if (arguments.result == -1) { if (errno == 0) errno = EINTR; // skip path leaves errno == 0 rb_sys_fail("my_syscall"); } ``` See "Errno handling" below for what `errno == EINTR` vs `errno == 0` tells you. Extensions can feature-detect the flag at build time so they keep working on older Rubies: ```c #ifdef RB_NOGVL_PENDING_INTERRUPT_FAIL flags |= RB_NOGVL_PENDING_INTERRUPT_FAIL; #endif ``` ## Errno handling On the pending-interrupt skip path, `rb_nogvl()` returns `0` with `errno == 0`. This matches the existing skip path used by `RB_NOGVL_INTR_FAIL`: when the function is never called, `errno` is restored to its initial value (`0`). The flag does not otherwise change `rb_nogvl()`'s `errno` behaviour, so this change is purely additive and carries no compatibility risk for existing extensions. For a caller, when an operation reports "no result" (e.g. `result == -1`), the two interesting outcomes can be told apart by `errno`: - `errno == EINTR` — the function **did** run and its syscall was actually interrupted (the conventional `EINTR`). Some side effects may have occurred. - `errno == 0` — the function did **not** run: it was skipped before entering the blocking region, either by `RB_NOGVL_PENDING_INTERRUPT_FAIL` (pending, possibly masked, interrupts) or by `RB_NOGVL_INTR_FAIL`. So for this proposal, `result == -1 && (errno == EINTR || errno == 0)` means the operation was not executed, or was interrupted — in both cases the caller should unwind and let Ruby process interrupts. An `errno` of `0` on a skipped callback is admittedly not very ergonomic (it forces the `if (errno == 0) errno = EINTR;` dance above before `rb_sys_fail()`). Making the skip paths report `EINTR` directly would remove that wrinkle, but it also erases the `EINTR`-vs-`0` distinction above (you could no longer tell a truly-interrupted syscall from a never-run one). That trade-off is a separate concern and may be proposed independently; this proposal keeps the existing behaviour and stays focused on the new flag. ## Implementation A reference implementation is available: - `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag: <https://github.com/ruby/ruby/pull/17553> Downstream user with feature detection and a fallback for older Rubies: - io-event: <https://github.com/socketry/io-event/pull/197> The focused CRuby C-API specs (`spec/ruby/optional/capi/thread_spec.rb`) cover the new flag: the function is not called when the current thread has masked pending interrupts, and `errno` is `0`. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126119] [Ruby Bug#22204] Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only)
by maxfelsher (Max Felsher) 18 Jul '26

18 Jul '26

Issue #22204 has been reported by maxfelsher (Max Felsher). ---------------------------------------- Bug #22204: Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only) https://bugs.ruby-lang.org/issues/22204 * Author: maxfelsher (Max Felsher) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require shows the following text: > When RubyGems is required, [`Kernel#require`](https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require) is replaced with our own which is capable of loading gems on demand. > > When you call `require 'x'`, this is what happens: > > * If the file can be loaded from the existing Ruby loadpath, it is. > * Otherwise, installed gems are searched for a file that matches. If it’s found in gem ‘y’, that gem is activated (added to the loadpath). > > The normal `require` functionality of returning false if that file has already been loaded is preserved. Clicking the "Source" button shows RubyGems' version of the method, with a comment indicating it was pulled from `# File lib/rubygems/core_ext/kernel_require.rb, line 36`. The same situation holds for https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-require (as well as the 3.3 and 3.2 documentation, for what it's worth). This seems to have been fixed on master: at this moment, https://docs.ruby-lang.org/en/master/Kernel.html#method-i-require shows documentation that makes more sense for a core method (starting with "Loads the given `name`, returning `true` if successful and `false` if the feature is already loaded"). I think the fix was in https://github.com/ruby/ruby/pull/16086, which referenced a GitHub issue describing the same problem described here. If the backport policy allows for this kind of fix to be backported, would it be possible to fix the documentation for Ruby 4.0 and 3.4 in addition to master? (I assume this is out of scope for 3.3 and 3.2.) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126087] [Ruby Bug#22196] Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10
by scohen-tines (seth cohen) 18 Jul '26

18 Jul '26

Issue #22196 has been reported by scohen-tines (seth cohen). ---------------------------------------- Bug #22196: Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10 https://bugs.ruby-lang.org/issues/22196 * Author: scohen-tines (seth cohen) * Status: Open * ruby -v: ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Heap-use-after-free in `fiber_switch` reading terminated fiber's status (regression via Bug #21955 backport) Ruby 3.4.10 intermittently segfaults while an async-http workload terminates task fibers after truncated chunked HTTP responses. The equivalent workload completed 20 high-churn attempts on Ruby 3.4.9 without a crash. ASan shows a heap-use-after-free: the outgoing fiber's `rb_fiber_t` is freed by GC while `fiber_switch` still reads its status on the `Fiber#transfer` path. ## Environment ```text ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] ``` - Linux `aarch64` Docker image. - `async-1.32.1`, `async-http-0.64.2`, and `async-pool-0.10.3`. - The ASan build uses `-fsanitize=address -fno-omit-frame-pointer -g -O0` and has YJIT disabled. ## Expected behavior An incomplete chunked HTTP response should fail its async task with `EOFError`; the VM should not crash while cleaning up the task fiber. ## Actual behavior Ruby exits with a segmentation fault in the fiber stack pool: ```text -- C level backtrace -- fiber_pool_stack_release fiber_stack_release fiber_switch rb_fiber_start ``` One GDB run on a source-built 3.4.10 reached: ```text #0 fiber_pool_stack_release (stack=0xffffc4012ea0) at cont.c:770 pool = 0x0 #1 fiber_stack_release (fiber=0xffffc4012b00) at cont.c:903 #2 fiber_switch (...) at cont.c:2728 ``` We first hit this in a production service; the harness below reproduces the same C-level frames using only async-http against a local server, with no application code. ## AddressSanitizer result An ASan build makes the bug deterministic. With 50 in-process request bursts, all five stock 3.4.10 runs report: ```text ERROR: AddressSanitizer: heap-use-after-free READ of size 1 #0 fiber_switch /src/ruby-3.4.10/cont.c:2727 ... freed by thread T2 here: cont_free /src/ruby-3.4.10/cont.c:1079 fiber_free /src/ruby-3.4.10/cont.c:1164 ... previously allocated by thread T3 here: fiber_t_alloc /src/ruby-3.4.10/cont.c:1986 SUMMARY: AddressSanitizer: heap-use-after-free /src/ruby-3.4.10/cont.c:2727 in fiber_switch ``` Line 2727 of `cont.c` is the new `FIBER_TERMINATED_P(fiber)` condition (see Regression candidate below). Thus the first invalid operation is reading the freed `rb_fiber_t` object's status. It occurs before `fiber_pool_stack_release`; the latter is a downstream manifestation when the stale status reads as terminated and the release branch continues. The full report is attached as `stock-1.log`. ## Minimal reproduction harness The attached harness consists of: - `repro.rb`: local raw HTTP server plus direct async-http client; - `Gemfile` and `Gemfile.lock`: pinned async dependencies; - `Dockerfile` and `run.sh`: repeat the workload on a stock Ruby image. Run: ```sh ./run.sh 3.4.10 20 ``` This is probabilistic; successful runs are expected. The harness retains a log for every attempt and reports the first interpreter crash. The workload synchronizes groups of ten failures by default: ```sh FAULT_BARRIER=10 ./run.sh 3.4.10 50 ``` Run the same source comparison under ASan (deterministic): ```sh BATCHES=50 ./run-asan.sh 5 ``` `./run.sh 3.4.9 20` completes all 20 attempts without a crash; 3.4.9 predates the `148f263a` backport. ## Regression candidate Ruby 3.4.10 includes ruby_3_4 commit [`148f263a`](https://github.com/ruby/ruby/commit/148f263a0d299e4532c753470a282144c9104820), the backport of [`dc1777d`](https://github.com/ruby/ruby/commit/dc1777d01770ab62ec99ff6fa4cf622098f44968) for [Bug #21955](https://bugs.ruby-lang.org/issues/21955). That changes `fiber_switch` as follows: ```diff - if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { + if (FIBER_TERMINATED_P(fiber)) { fiber_stack_release(fiber); } ``` `Fiber#transfer` passes a null `resuming_fiber`, so the old condition short-circuited without reading `fiber->status`. The new condition dereferences the stale `fiber` pointer before deciding whether to release its stack. We have not tested ruby-head/3.5, but the same condition is present there since `dc1777d`, so we expect it to be affected. ## Controlled source comparison The harness also includes: ```sh BATCHES=20 ./run-ab.sh 20 ``` It builds the published Ruby 3.4.10 source twice with the same compiler and workload: 1. stock 3.4.10; 2. 3.4.10 with only the above condition restored to `resuming_fiber && FIBER_TERMINATED_P(fiber)`. | Build | Attempts | `fiber_pool_stack_release` crashes | | --- | ---: | ---: | | stock 3.4.10 | 20 | 4 | | 3.4.10 with Bug #21955 condition reverted | 20 | 0 | The stock run also had one additional process abort with: ```text malloc(): unaligned tcache chunk detected ``` All 20 reverted-build processes completed successfully. These runs used `BATCHES=20`, 100 requests per batch, concurrency 20, and a barrier of 10 simultaneous truncated responses. The image is built from the Ruby 3.4.10 release tarball with `-O0 -g3 -fno-omit-frame-pointer`; the only source difference between the two images is the condition shown above. The ASan A/B uses `BATCHES=50`: all 5 stock runs report the above heap-use-after-free, while all 5 reverted runs complete cleanly. ## Request Could the fiber maintainers review why a `rb_fiber_t` can be finalized by GC while `fiber_switch` still holds it as the outgoing fiber? Reinstating the `resuming_fiber` guard avoids the dereference on the transfer path, but a proper fix likely needs to ensure that the outgoing fiber remains live through the switch or otherwise avoid reading it after its lifetime ends. ---Files-------------------------------- ruby-3.4.10-fiber-uaf.tar.gz (19.7 KB) stock-1.log (58.4 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125882] [Ruby Feature#22135] Remove deprecated `ObjectSpace#_id2ref`
by nobu (Nobuyoshi Nakada) 17 Jul '26

17 Jul '26

Issue #22135 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22135: Remove deprecated `ObjectSpace#_id2ref` https://bugs.ruby-lang.org/issues/22135 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- As a result of [Feature #15408], the `ObjectSpace#_id2ref` method has been deprecated and now triggers a warning. However, we recognize that its use had already been discouraged for a long time prior to this, and we believe it is rarely used nowadays. Are there any objections to removing this method in version 4.1? [GH-17577](https://github.com/ruby/ruby/pull/17577) -- https://bugs.ruby-lang.org/

8 7

[ruby-core:126113] [Ruby Feature#22202] Add Coverage.branch_stub and Coverage.method_stub as companions to Coverage.line_stub
by sferik (Erik Berlin) 17 Jul '26

17 Jul '26

Issue #22202 has been reported by sferik (Erik Berlin). ---------------------------------------- Feature #22202: Add Coverage.branch_stub and Coverage.method_stub as companions to Coverage.line_stub https://bugs.ruby-lang.org/issues/22202 * Author: sferik (Erik Berlin) * Status: Open ---------------------------------------- `Coverage.line_stub(path)` compiles a file and returns its line coverage array as if the file had been loaded but never run. SimpleCov uses this method to include never-loaded files in a report so that their lines count toward the denominator. But there is no equivalent for branch or method coverage. A tool that wants a never-loaded file to participate in branch or method totals must reconstruct the structures itself with a parser. The difficulty is that reconstruction must match the VM byte-for-byte. Merged coverage reports key branches and methods on their full location tuples, for example `[:if, id, start_line, start_col, end_line, end_col]`. If a tool synthesizes a tuple whose location differs from what the VM records for the same construct, merging a synthesized entry with a real one produces a duplicate branch that no execution can ever hit. The report then shows a permanently missed branch in a fully covered file. These location conventions are not documented and they change between Ruby versions. Cases SimpleCov has had to reverse engineer recently: 1. The range of an `elsif` clause changed between Ruby 3.3 and 3.4 (https://github.com/simplecov-ruby/simplecov/issues/1226) 2. A safe navigation call followed by a block ends its branch range at the call, excluding the block (https://github.com/simplecov-ruby/simplecov/issues/1233) 3. Conditions that are compile-time literals (`if true`, ternary on an integer) are folded and produce no branch at all, while `while true` still does. 4. On Ruby 3.3 the location of an empty branch arm depends on whether the construct is in value or void position. Ruby 3.4 removed this distinction. 5. `x => pattern` and `x in pattern` produce a `:case` branch on Ruby 3.3 and nothing on 3.4. SimpleCov now carries roughly 500 lines of Prism-based reconstruction plus a differential fuzzer that compiles thousands of generated programs under real Coverage and diffs the tuples, only to keep parity with conventions the VM already knows. Each new Ruby version can silently change a convention and reintroduce this class of bug. #### Proposal Add two class methods to the Coverage standard library: ```ruby require "coverage" Coverage.branch_stub("foo.rb") # => {[:if, 0, 2, 2, 6, 5] => {[:then, 1, 3, 4, 3, 10] => 0, [:else, 2, 5, 4, 5, 10] => 0}} Coverage.method_stub("foo.rb") # => {["Foo", :bar, 2, 2, 4, 5] => 0} ``` Return value shapes are identical to `Coverage.result[path][:branches]` and `Coverage.result[path][:methods]` so existing merge code works unchanged. Like `line_stub`, the file is compiled but not executed, and Coverage does not need to be running. It should raise the same errors `line_stub` raises for missing or unparsable files. The VM already computes these structures at compile time whenever coverage is enabled with `branches: true` or `methods: true`. `line_stub` is implemented by compiling the file and walking `iseq.trace_points`. A similar approach should work here. I am happy to help with a patch if this direction is acceptable. -- https://bugs.ruby-lang.org/

2 1

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

17 Jul '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/

2 1