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

[ruby-core:126105] [Ruby Bug#22200] ObjectSpace._id2ref can return a different object than the id's owner on Ruby 4.0 (stale id2ref_tbl entry for objects with generic fields)
by navidemad (Navid Emad) 19 Jul '26

19 Jul '26

Issue #22200 has been reported by navidemad (Navid Emad). ---------------------------------------- Bug #22200: ObjectSpace._id2ref can return a different object than the id's owner on Ruby 4.0 (stale id2ref_tbl entry for objects with generic fields) https://bugs.ruby-lang.org/issues/22200 * Author: navidemad (Navid Emad) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin23] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On Ruby 4.0.x, `ObjectSpace._id2ref(id)` can return a **different, unrelated live object** instead of raising `RangeError`, after the object that owned the id has been garbage collected and its heap slot reused. Observed returns in the reproduction below include recycled strings, `Thread::Backtrace` instances and previously-raised `RangeError` exception objects. Ruby ≤ 3.4 is not affected. Ruby master is not affected because `_id2ref` was removed ([Feature #22135], commit df062232), so this is a 4.0-branch-only bug — but 4.0 is the current stable release and `_id2ref` is still callable there (with a deprecation warning). Tested and reproduced on 4.0.2, 4.0.5 and 4.0.6 (arm64-darwin23); production crashes caused by the same mechanism were observed on 4.0.5 x86_64-linux (see "Real-world impact"). ## Root cause Since the object_id redesign ([Feature #15408]), the id lives in the object itself and `id2ref_tbl` (lazily built on first `_id2ref` call) is the only id → object mapping. Entry deletion happens in `obj_free_object_id`, called from sweep via `rb_gc_obj_free_vm_weak_references`, and depends on where the id is stored (gc.c, v4.0.5, `obj_free_object_id`): * `T_OBJECT` (id in its own fields) and `T_CLASS`/`T_MODULE` (id in `RCLASS->object_id`): the entry is deleted when the owner itself is swept — same as ≤ 3.4. * **Every other type** (String, Array, Hash, Data, ... — id stored in the companion `T_IMEMO/fields`): the owner's sweep hits `default: return;` ("For generic_fields, the T_IMEMO/fields is responsible for freeing the id") and only detaches the imemo via `rb_free_generic_ivar`, which does not touch `id2ref_tbl`. The entry is deleted only when **the imemo is swept**. The owner and its imemo generally live in different size pools, so under lazy sweeping their sweeps are separated by arbitrary amounts of Ruby execution. In that window `id2ref_tbl` still maps a valid id to a freed slot. The only gate on lookup is `rb_gc_impl_garbage_object_p`, which catches `T_NONE`/`T_MOVED`/`T_ZOMBIE` and unswept garbage during lazy sweeping — it cannot catch a *recycled* slot, whose new occupant is a perfectly live object. `object_id_to_ref` then returns that occupant instead of raising `RangeError`. (Note the weak-table pass over `id2ref_tbl` via `rb_gc_vm_weak_table_foreach` only runs during compaction reference updating, so ordinary GC cycles never purge these dangling entries.) On ≤ 3.4 this window cannot exist: `obj_free_object_id` deleted both `obj_to_id_tbl`/`id_to_obj_tbl` entries for every freed object in the same sweep step that frees the slot. ## Reproduction ```ruby # MODE=string -> owners are Strings (generic fields, deferred deletion) => bug on 4.0 # MODE=object -> owners are T_OBJECTs (id in own fields, eager deletion) => control Warning[:deprecated] = false OWNERS = Integer(ENV["OWNERS"] || 50_000) MODE = ENV["MODE"] || "string" BATCHES = Integer(ENV["BATCHES"] || 60) PROBES_PER_BATCH = Integer(ENV["PROBES_PER_BATCH"] || 300) RECYCLERS_PER_BATCH = Integer(ENV["RECYCLERS_PER_BATCH"] || 1_000) srand(42) def probe(id) ObjectSpace._id2ref(id) end # Make id2ref_tbl exist before owners get their ids, so each object_id call # inserts an entry (gc.c object_id0). anchor = Object.new probe(anchor.object_id) # Allocate all owners first (their pages come earlier in sweep order), then # take object_ids afterwards (imemos land on later pages / another pool). owners = if MODE == "string" Array.new(OWNERS) { |i| +"owner-#{i}" } else Array.new(OWNERS) { |i| o = Object.new; o.instance_variable_set(:@owner, i); o } end ids = owners.map(&:object_id) owners = nil GC.start(full_mark: true, immediate_sweep: false) dead = 0 alive_original = 0 wrong = Hash.new(0) wrong_samples = [] recyclers = [] BATCHES.times do |batch| recyclers.concat(Array.new(RECYCLERS_PER_BATCH) { +"recycler-#{batch}" }) PROBES_PER_BATCH.times do id = ids.sample begin obj = probe(id) original = if MODE == "string" obj.instance_of?(String) && obj.start_with?("owner-") else obj.instance_of?(Object) && obj.instance_variable_defined?(:@owner) end if original alive_original += 1 # kept alive by conservative stack refs; not a bug else wrong[obj.class] += 1 wrong_samples << obj.inspect[0, 60] if wrong_samples.size < 10 end rescue RangeError dead += 1 end end end puts RUBY_DESCRIPTION puts "mode=#{MODE} owners=#{OWNERS}" puts " RangeError (correct): #{dead}" puts " returned original (alive): #{alive_original}" puts " returned WRONG object (BUG): #{wrong.values.sum} #{wrong.sort_by { |_, v| -v }.to_h}" wrong_samples.each { |s| puts " e.g. #{s}" } exit(wrong.values.sum > 0 ? 1 : 0) ``` Results (18,000 probes per run): | Ruby | owners | wrong-object returns | |---|---|---| | 4.0.2 | String (generic fields) | 4 | | 4.0.5 | String (generic fields) | 12 | | 4.0.6 | String (generic fields) | 12 | | 4.0.5 | `T_OBJECT` (control) | 0 | | 3.4.10 | String (control) | 0 | Sample of what `_id2ref(dead_string_id)` returned instead of raising, on 4.0.6: ``` "recycler-0" # the object recycled into the slot #<Thread::Backtrace:0x0000000122507710> # a VM-internal object #<RangeError: "67488" is a recycled object> # an exception raised by an earlier probe ``` Two notes for reproducing: * `GC.disable` must not be used: under `dont_gc`, allocation never drives lazy sweeping (`heap_prepare` grows the heap instead), so slots are never recycled and every probe is correctly caught by the unswept-garbage branch of `rb_gc_impl_garbage_object_p`. * The dangling-entry zone moves with the sweep cursors (`gc_sweep_continue` advances one page in every heap per step), hence the randomly-sampled probes. ## Real-world impact This is the root cause of https://github.com/DataDog/dd-trace-rb/issues/5936: the datadog gem's heap profiler tracks sampled objects by object_id and resurrects them with `_id2ref` at serialization time, relying on the ≤ 3.4 contract "the exact object or `RangeError`". On 4.0 it receives arbitrary slot occupants and calls `rb_obj_memsize_of()` on them; production crash dumps show SIGSEGVs in three distinct type branches of `rb_obj_memsize_of` (`T_CLASS` classext walk, `T_REGEXP` `onig_memsize`, `T_DATA` `rb_objspace_data_type_memsize`) — full dumps in https://gist.github.com/navidemad/e6ed6e38fad5b3ebe9e89f553f7562ba. Datadog has since disabled the feature on 4.0 (https://github.com/DataDog/dd-trace-rb/pull/6022) Beyond that particular consumer, `_id2ref` handing out arbitrary live objects (including VM-internal ones like `Thread::Backtrace`) to any caller holding a stale integer id seems undesirable for remaining `_id2ref` users (e.g. DRb) even during the deprecation period. ## Possible fix direction At owner sweep time the id is no longer reachable from the owner (its shape may already have been reset by the generic-fields weak-table pass), so the natural place to delete the `id2ref_tbl` entry for a dead generic-fields owner appears to be the GC's weak-table processing of `generic_fields_tbl` (`vm_weak_table_gen_fields_foreach`, `ST_DELETE` case): at that point the imemo is still intact, so its id can be read and the `id2ref_tbl` entry removed there, restoring the ≤ 3.4 guarantee that an entry never outlives its owner. [Feature #15408]: https://bugs.ruby-lang.org/issues/15408 [Feature #22135]: https://bugs.ruby-lang.org/issues/22135 -- https://bugs.ruby-lang.org/

4 3

[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) 19 Jul '26

19 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) 18 Jul '26

18 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:126115] [Ruby Bug#22203] Coverage (eval: true): branch entries for re-eval'd code are nondeterministically duplicated
by sferik (Erik Berlin) 17 Jul '26

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

1 0

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

17 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 14

[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

[ruby-core:126106] [Ruby Bug#22201] ruby.exe reads `"AA\ " BB` as a single argument
by mame (Yusuke Endoh) 17 Jul '26

17 Jul '26

Issue #22201 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22201: ruby.exe reads `"AA\ " BB` as a single argument https://bugs.ruby-lang.org/issues/22201 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A backslash escapes a double quote that sits beyond a whitespace character. ``` C:\> ruby -e "p ARGV" "AA\ " BB ["AA\\ BB"] # <- actual ["AA\\ ", "BB"] # <- expected ``` This is not intentional, right? The escape is cancelled when almost any other character appears, but I think whitespace seems to have been simply forgotten. The fix is so simple: ``` --- a/win32/win32.c +++ b/win32/win32.c @@ -1739,6 +1739,15 @@ w32_cmdvector(const WCHAR *cmd, char ***vec, UINT cp, rb_encoding *enc) *ptr = 0; done = 1; } + slashes = 0; break; case L'*': ``` https://github.com/ruby/ruby/pull/17943 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126104] [Ruby Bug#22199] win32: Kernel#system: `AA BB\` arrives as `AA BB"`
by mame (Yusuke Endoh) 17 Jul '26

17 Jul '26

Issue #22199 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22199: win32: Kernel#system: `AA BB\` arrives as `AA BB"` https://bugs.ruby-lang.org/issues/22199 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: windows * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` PS C:\> ruby -ve "system('python3','-c','import sys; print(sys.argv[1])', 'AA BB\\')" ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] AA BB" ``` `AA BB\` was passed to `Kernel#system`, but python3.exe read it as `AA BB"`. What happens: * `Kernel#system` creates and passes the command line string `python3 ... "AA BB\"` to `CreateProcessW`, and * python3.exe (and anything else using the VC Runtime's command line parser) reads `"AA BB\"` as an (accidentally unterminated) `AA BB"`. It reproduces when an argument contains a space and ends with `\`. When an argument contains a space, `Kernel#system` wraps it in double quotes. If the argument also ends with `\`, that backslash is taken to escape the closing quote. `Kernel#system` should escape the final backslash(es) when it wraps an argument that ends with one. In the example above it should pass `python3 ... "AA BB\\"` to `CreateProcessW`. Here is a PR for that: https://github.com/ruby/ruby/pull/17941 Note that cmd.exe and batch files do not interpret backslash escapes, so the backslash must NOT be escaped when calling those. The PR escapes only when (1) the call does not go through cmd.exe, (2) the argument is wrapped in double quotes, and (3) the argument ends with `\`. -- https://bugs.ruby-lang.org/

1 0