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

[ruby-core:117658] [Ruby master Feature#20448] Make coverage event hooking C API public
by ms-tob (Matt S) 09 Aug '26

09 Aug '26

Issue #20448 has been reported by ms-tob (Matt S). ---------------------------------------- Feature #20448: Make coverage event hooking C API public https://bugs.ruby-lang.org/issues/20448 * Author: ms-tob (Matt S) * Status: Open ---------------------------------------- # Abstract Gathering code coverage information is a well-known goal within software engineering. It is most commonly used to assess code coverage during automated testing. A lesser known use-case is coverage-guided fuzz testing, which will be the primary use-case presented in this issue. This issue exists to request that Ruby coverage event hooking be made part of its official, public C API. # Background Ruby currently provides a number of avenues for hooking events *or* gathering coverage information: 1. The [Coverage](https://ruby-doc.org/3.3.0/exts/coverage/Coverage.html) module 2. The [TracePoint](https://ruby-doc.org/3.3.0/TracePoint.html) module 3. The [rb_add_event_hook](https://ruby-doc.org/3.3.0/extension_rdoc.html#label-Hoo… extension function Unfortunately, none of these pieces of functionality solve this issue's specific use-case. The `Coverage` module is not a great fit for real-time coverage analysis with an unknown start and stop point. Coverage-guided fuzz testing requires this. The `TracePoint` module and `rb_add_event_hook` are not able to hook branch and line coverage events. Coverage-guided fuzz testing typically tracks branch events. # Proposal The ultimate goal is to enable Ruby C extensions to process coverage events in real-time. I did some cursory investigation into the Ruby C internals to determine what it would take to achieve this, but I'm by no means an expert, so my list may be incomplete. The good news is that much of this functionality already exists, but it's part of the private, internal-only C API. 1. Make `RUBY_EVENT_COVERAGE_LINE` and `RUBY_EVENT_COVERAGE_BRANCH` public: https://github.com/ruby/ruby/blob/v3_3_0/vm_core.h#L2182-L2184 a. This would be an addition to the current public event types: https://github.com/ruby/ruby/blob/v3_3_0/include/ruby/internal/event.h#L32-… 2. Allow initializing global coverage state so that coverage tracking can be fully enabled a. Currently, if `Coverage.setup` or `Coverage.start` is not called, then coverage events cannot be hooked. I do not fully understand why this is, but I believe it has something to do with `rb_get_coverages` and `rb_set_coverages`. If calls to `rb_get_coverages` return `NULL` (https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L641-L647, https://github.com/ruby/ruby/blob/v3_3_0/iseq.c#L864-L868) then coverage hooking will not be enabled. I believe the `Coverage` module initializes that state via a `rb_set_coverages` call here: https://github.com/ruby/ruby/blob/v3_3_0/ext/coverage/coverage.c#L112-L120. b. So, to achieve this goal, a C extension would need to be able to call `rb_set_coverages` or somehow initialize the global coverage state. I've actually been able to achieve this functionality by calling undocumented features and defining `RUBY_EVENT_COVERAGE_BRANCH`: ```c #include <ruby.h> #include <ruby/debug.h> #define RUBY_EVENT_COVERAGE_BRANCH 0x020000 // ... rb_event_flag_t events = RUBY_EVENT_COVERAGE_BRANCH; rb_event_hook_flag_t flags = ( RUBY_EVENT_HOOK_FLAG_SAFE | RUBY_EVENT_HOOK_FLAG_RAW_ARG ); rb_add_event_hook2( (rb_event_hook_func_t) event_hook_branch, events, counter_hash, flags ); ``` If I call `Coverage.setup(branches: true)`, and add this event hook, then branch hooking works as expected. `rb_add_event_hook2` will still respect the `RUBY_EVENT_COVERAGE_BRANCH` value if its passed. But it would be better if I could rely on official functionality rather than undocumented features. The above two points would be requirements for this functionality, but there's an additional nice-to-have: 3. Extend the public `tracearg` functionality to include additional coverage information a. Currently, `tracearg` offers information like `rb_tracearg_lineno` and `rb_tracearg_path`. It would be helpful if it also provided additional coverage information like `coverage.c`'s column information and a unique identifier for each branch. Currently, I can only use `(path, lineno)` as a unique identifier for a branch because that's what's offered by the public API, but more information like column number would be helpful for uniquely identify branches. Since there can be multiple `if` statements on a single line, this can provide ambiguous identification for a branch event. # Use cases This use-case was born out of a new coverage-guided Ruby fuzzer: https://github.com/trailofbits/ruzzy. You can read more about its implementation details here: https://blog.trailofbits.com/2024/03/29/introducing-ruzzy-a-coverage-guided…. You can also find the Ruby C extension code behind its implementation here: https://github.com/trailofbits/ruzzy/blob/v0.7.0/ext/cruzzy/cruzzy.c#L220-L…. So, the primary use-case here is enabling real-time, coverage-guided fuzz testing of Ruby code. However, as mentioned in the abstract, gathering code coverage information is useful in many domains. For example, it could enable new workflows in standard unit/integration test coverage. It could also enable gathering coverage information in real-time as an application is running. I see this as the most generalized form of gathering code coverage information, and something like the `Coverage` module as a specialized implementation. Another example, https://bugs.ruby-lang.org/issues/20282 may be solved by this more generalized solution. We are tracking this request downstream here: https://github.com/trailofbits/ruzzy/issues/9 # Discussion Fuzz testing is another tool in a testers toolbelt. It is an increasingly common way to improve software's robustness. Go has it built in to the standard library, Python has Atheris, Java has Jazzer, JavaScript has Jazzer.js, etc. OSS-Fuzz has helped identify and fix over 10,000 vulnerabilities and 36,000 bugs [using fuzzing](https://google.github.io/oss-fuzz/#trophies). Ruby deserves a good fuzzer, and improving coverage gathering would help achieve that goal. The `Coverage` module, `TracePoint` module, and `rb_add_event_hook` function seem like they could fulfill this goal. However, after deeper investigation, none of them fit the exact requirements for this use-case. # See also - https://bugs.ruby-lang.org/issues/20282 - https://github.com/google/atheris - https://security.googleblog.com/2020/12/how-atheris-python-fuzzer-works.html - https://github.com/CodeIntelligenceTesting/jazzer/ - https://www.code-intelligence.com/blog/java-fuzzing-with-jazzer - https://go.dev/doc/security/fuzz/ -- https://bugs.ruby-lang.org/

3 11

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 08 Aug '26

08 Aug '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

6 32

[ruby-core:126070] [Ruby Bug#22193] Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides
by KitaitiMakoto 08 Aug '26

08 Aug '26

Issue #22193 has been reported by KitaitiMakoto (真北市). ---------------------------------------- Bug #22193: Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides https://bugs.ruby-lang.org/issues/22193 * Author: KitaitiMakoto (真北市) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-13T13:26:16Z origin/master cb2ea293c6) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I encountered a segmentation fault when calling `rb_memory_view_is_row_major_contiguous` with a MemoryView whose shape and strides are `NULL`. For instance, a MemoryView initialized with `rb_memory_view_init_as_byte_array` function causes this problem. The cause is that the function handles `shape` and `strides` as arrays without checking whether they are `NULL` or not. Environment ----------- * Ruby commit: cb2ea293c6 * OS: macOS (M2 Mac) Code to reproduce the problem: ------------------------------ I will send a pull request later for the full patch. ### ext/-test-/memory_view/memory_view.c ### ```c static VALUE memory_view_is_row_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_row_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } static VALUE memory_view_is_column_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_column_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } // ... void Init_memory_view(void) { // ... rb_define_module_function(mMemoryViewTestUtils, "is_row_major_contiguous", memory_view_is_row_major_contiguous, 1); rb_define_module_function(mMemoryViewTestUtils, "is_column_major_contiguous", memory_view_is_column_major_contiguous, 1); // ... } ``` ### test/ruby/test_memory_view.rb ### ```ruby class TestMemoryView < Test::Unit::TestCase # ... def test_rb_memory_view_is_row_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_row_major_contiguous(es)) end def test_rb_memory_view_is_column_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_column_major_contiguous(es)) end # ... end ``` Steps to reproduce the problem: ------------------------------- 1. Add code above to the current Ruby (cb2ea293c6) 2. Run `make test-all TESTS=test/ruby/test_memory_view.rb` 3. Then you can see segmentation fault Thank you. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:124714] [Ruby Bug#21870] Regexp: Warnings when using multiple non-overlapping \p{...} classes
by jneen (Jeanine Adkisson) 07 Aug '26

07 Aug '26

Issue #21870 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21870: Regexp: Warnings when using multiple non-overlapping \p{...} classes https://bugs.ruby-lang.org/issues/21870 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.0, 4.0.1, earlier versions to a lesser extent * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby $VERBOSE = true # warning: character class has duplicated range: /[\p{Word}\p{S}]/ regex = /[\p{Word}\p{S}]/ ``` As far as I can tell this is a perfectly valid and non-overlapping set of unicode properties, but I am still being spammed with warnings. Using `/(\p{Word}|\p{S})/` is kind of a workaround, but it is slower. -- https://bugs.ruby-lang.org/

9 23

[ruby-core:124418] [Ruby Feature#21826] Deprecating RubyVM::AbstractSyntaxTree
by Eregon (Benoit Daloze) 07 Aug '26

07 Aug '26

Issue #21826 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21826: Deprecating RubyVM::AbstractSyntaxTree https://bugs.ruby-lang.org/issues/21826 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I think it is time to deprecate `RubyVM::AbstractSyntaxTree`. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/) so it's clear the official Ruby parsing API is the Prism API. `RubyVM::AbstractSyntaxTree` is CRuby-specific and does not work on any other Ruby implementation, the API is unstable, inconvenient, etc: > This module is experimental and its API is not stable, therefore it > might change without notice. As examples, the order of children nodes is > not guaranteed, the number of children nodes might change, there is no > way to access children nodes by name, etc. Because it's under `RubyVM`, it also has the following documented caveats: > This module is for very limited purposes, such as debugging, prototyping, and research. > Normal users must not use it. This module is not portable between Ruby implementations. Given these caveats I think it could possibly be fair enough to remove it without deprecation, however I see no urgency to remove it straight away so I think having it deprecated for one release is nicer for the few gems using it. The advantages of deprecating it are: * Make it clear that this API should not be used in new code * Encourage the few usages to migrate to the Prism API, which is stable, officially supported, designed with many people to be usable and convenient for every parsing/tooling usage, etc. * Improve portability of Ruby code between Ruby implementations So, let's deprecate `RubyVM::AbstractSyntaxTree` in 4.1, and remove it in 4.2? -- https://bugs.ruby-lang.org/

5 6

[ruby-core:125966] [Ruby Feature#22186] Increase the embeddable size limit for substrings created by `str_subseq()`
by himura467 (Akito Shitara) 07 Aug '26

07 Aug '26

Issue #22186 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22186: Increase the embeddable size limit for substrings created by `str_subseq()` https://bugs.ruby-lang.org/issues/22186 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ## Summary `str_subseq()` unnecessarily limits how large a sharable middle substring can be while still being embedded into the new `RString`. Substrings roughly 24 to 1000 bytes long (on a 64-bit build) always take the shared path, even though variable width allocation (VWA, Feature #18239) already supports embedding objects of that size. I propose sizing the allocation to the actual substring length via `STR_EMBEDDABLE_P()` / `str_alloc_embed()`, the same pattern used by other allocation sites in `string.c`, instead of allocating through `str_alloc_heap()` and checking whether the substring fits in the smallest heap slot class. ## Background For a sharable substring (per `SHARABLE_SUBSTRING_P`), `str_subseq()` either embeds the bytes directly into the new `RString`, or shares the parent's heap buffer, which keeps the parent alive. Since [commit 132f097149](https://github.com/ruby/ruby/commit/132f097149af36cb77308d9fe1c…, the decision has been: ```c str2 = str_alloc_heap(rb_cString); if (str_embed_capa(str2) >= len + termlen) { // embed } else { // share } ``` `str_alloc_heap()` always allocates the default `sizeof(struct RString)` slot regardless of `len`, so `str_embed_capa(str2)` is capped at roughly 23 bytes. Meanwhile the default GC's size pools go up to 1024 bytes on 64-bit builds, and other allocation sites (`str_enc_new` behind `rb_str_new`, `rb_str_buf_new`, `str_new_frozen_buffer`, `rb_str_times`, ...) already pick the right-sized slot via `STR_EMBEDDABLE_P()` / `str_alloc_embed()`. ## Proposed change Draft PR: https://github.com/ruby/ruby/pull/17723 Check `STR_EMBEDDABLE_P(len, termlen)` up front and allocate with `str_alloc_embed()`; only allocate the `STR_NOEMBED` heap object on the sharing branch. Behavior is unchanged for substrings that aren't sharable or that reach the end of the parent's buffer. Only the threshold at which a sharable middle substring switches from embedding to sharing grows. ## Benchmark results Using [ruby-bench](https://github.com/ruby/ruby-bench), this branch vs current master (`arm64-darwin25`, `+PRISM`). Top 3 and bottom 3 by ratio (master/branch, higher is better): | bench | master (ms) | current (ms) | ratio | | ---- | ---- | ---- | ----- | | fluentd | 258.6 | 230.8 | 1.120 | | ruby-json | 154.1 | 150.2 | 1.026 | | liquid-c | 31.2 | 30.6 | 1.022 | | graphql-native | 172.0 | 174.9 | 0.983 | | activerecord | 148.7 | 153.0 | 0.972 | | psych-load | 1244.9 | 1291.4 | 0.964 | Note that most except fluentd varies between runs. The fluentd improvement reproduces across runs, while the entries in the bottom 3 do not. So the few 2-4% slowdowns may be noise, but I'd like to verify them with more runs and machines before treating this as risk-free. ## Relation to Feature #19315 #19315 (sharable middle substrings) addresses the same underlying problem: middle substrings copy unnecessarily. The branch benchmarked in https://bugs.ruby-lang.org/issues/19315#note-52 actually included this embed size change as one of its commits, in addition to enabling `SHARABLE_MIDDLE_SUBSTRING`. To isolate the two, I benchmarked a variant of that branch with only the embed size change reverted ([rstring-raw-ptr-reverted](https://github.com/himura467/ruby/tree/rstring-ra…) alongside this proposal, against the same master: | bench | master (ms) | this proposal (ms) | #19315 without this change (ms) | | ---- | ---- | ---- | ---- | | fluentd | 256.9 | 207.2 (x1.240) | 255.6 (x1.005) | The clear `fluentd` improvement seen in note-52 reproduces with this change alone, and disappears when this change is reverted from the #19315 branch. So the practical win observed on ruby-bench so far is attributable to the larger embed threshold rather than to `SHARABLE_MIDDLE_SUBSTRING` itself. Beyond that, this change is much narrower: - A self-contained fix to one function, reusing the VWA embedding infrastructure already battle-tested elsewhere in `string.c`. - No API/ABI implications; `RSTRING_PTR()`'s `\0`-termination guarantee is untouched. - No memory-retention risk, since embedding copies the bytes instead of referencing the parent. The two are orthogonal (#19315 still helps for slices too large to embed, as its micro-benchmarks show), but this smaller fix seems worth landing first on its own merits. ---Files-------------------------------- output_001.txt (7.76 KB) output_001-ratio-current.png (184 KB) output_002.txt (14.9 KB) -- https://bugs.ruby-lang.org/

3 15

[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) 06 Aug '26

06 Aug '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/

5 7

[ruby-core:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 06 Aug '26

06 Aug '26

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

8 21

[ruby-core:126211] [Ruby Feature#22222] Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary`
by byroot (Jean Boussier) 06 Aug '26

06 Aug '26

Issue #22222 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22222: Expose a C API equivalent of `RubyVM::InstructionSequence.load_from_binary` https://bugs.ruby-lang.org/issues/22222 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Currently the only API to deserialize instruction sequence is `RubyVM::InstructionSequence.load_from_binary(String)`. It works fine, but isn't ideal for gems like bootsnap, as it needs to allocate a fairly large string and `memcpy` into it. I would like to be able to directly pass a `char *ptr` and `size_t len` pair, so that I can directly pass a internal buffer or even mmapped file. Proposed API: ``` VALUE rb_iseq_load_from_binary(const char *ptr, size_t len) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:126092] [Ruby Bug#22197] Backtraces show methods which do not exist
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22197 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22197: Backtraces show methods which do not exist https://bugs.ruby-lang.org/issues/22197 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class Parent def original puts caller_locations(0), nil end end class Child < Parent alias_method :alias, :original end Child.new.alias module Original def original puts caller_locations(0) end end class A define_method(:a, Original.instance_method(:original)) end A.new.a ``` gives: ``` $ ruby -v backtrace_alias.rb ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] backtrace_alias.rb:3:in 'Child#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'A#original' backtrace_alias.rb:23:in '<main>' ``` But this seems clearly incorrect: * there is no `Child#original`, there is only `Parent#original` and `Child#alias`. * there is no `A#original`, there is only `Original#original` and `A#a`. This behavior exists since Ruby 3.4 which added the module name in backtraces (#19117). So the issue is that backtraces show the "original method name from the definition" with the "method owner of the actually-called method". It should be consistent to avoid showing methods which don't exist. And it should be the original method from the definition, because we show the file and line of that, so we should also show the original name (already the case) and the original module (not the case yet, the bug). FWIW TruffleRuby already behaves like that: ``` $ truffleruby 34.0.1 (2026-04-26), like ruby 3.4.9, Oracle GraalVM Native [arm64-darwin23] backtrace_alias.rb:3:in 'Parent#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'Original#original' backtrace_alias.rb:23:in '<main>' ``` In #19117 there was some discussion about this, notably: https://bugs.ruby-lang.org/issues/19117#note-17 @byroot > My suggestion is for the owner. Simply put because it matches the path and other existing method representations. But actually the owner isn't that, what is described here is the original module of the method definition, same as the expected from this issue. https://bugs.ruby-lang.org/issues/19117#note-18 @eregon > It must be the owner, anything else would be very confusing. > I believe nobody wants String#then (there is no such method), they want to see Kernel#then. Where I was wrong about owner being the only thing. I was also expressing we should show where the method is defined, but I overlooked the "originally" part (aliases, define_method, etc). Also CC @mame who implemented the change. I think this is worth fixing for Ruby 4.1 (not sure if worth backporting). -- https://bugs.ruby-lang.org/

3 4