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

[ruby-core:126666] [Ruby Bug#18061] Execshield test: libruby.so.N.N.N: FAIL: property-note test because no .note.gnu.property section found
by ioquatix (Samuel Williams) 11 Sep '26

11 Sep '26

Issue #18061 has been updated by ioquatix (Samuel Williams). Status changed from Closed to Open Assignee changed from kjtsanaktsidis (KJ Tsanaktsidis) to ioquatix (Samuel Williams) I am implementing proper shadow stack support, since the Linux ABI/system calls is now stable. https://github.com/ruby/ruby/pull/5895 ---------------------------------------- Bug #18061: Execshield test: libruby.so.N.N.N: FAIL: property-note test because no .note.gnu.property section found https://bugs.ruby-lang.org/issues/18061#change-118960 * Author: jaruga (Jun Aruga) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 2.6: UNKNOWN, 2.7: REQUIRED, 3.0: REQUIRED ---------------------------------------- I found an issue in our company's internal test called "execshield" by a security tool annobin - annocheck command [1][2]. ``` Hardened: libruby.so.2.7.4: FAIL: property-note test because no .note.gnu.property section found ``` Here is the reproducer on the upstream latest master, commit is 5f2987d6c2ae9ace3178ac3e1bbb4ac7079101eb, ``` $ autoconf $ ./configure --enable-shared $ make $ ls libruby.so.3.1.0 libruby.so.3.1.0* ``` If you are using Red Hat based Linux distro, it's easy to install by the RPM package like this. ``` $ sudo dnf -y install annobin-annocheck ``` ``` $ sudo yum -y install annobin-annocheck ``` Then ``` $ annocheck libruby.so.3.1.0 ``` If you are using other Linux distros such as Ubuntu, you can use it by a container I prepared. Prepare the following `Dockerfile`. ``` $ cat Dockerfile FROM docker.io/fedora:34 RUN cat /etc/fedora-release RUN dnf -y install annobin-annocheck WORKDIR /work ``` Then build the container image with the `Dockerfile` and run the annocheck command for the `libruby.so.3.1.0` on your host environment. The `-v` is an option for bind mount between host and container environment. ``` $ docker build --rm -t fedora-annocheck . $ docker run --rm -t -v $(pwd):/work fedora-annocheck annocheck /work/libruby.so.3.1.0 annocheck: Version 9.79. Hardened: libruby.so.3.1.0: FAIL: bind-now test because not linked with -Wl,-z,now Hardened: libruby.so.3.1.0: FAIL: notes test because gaps were detected in the annobin coverage Hardened: libruby.so.3.1.0: FAIL: cf-protection test because no .note.gnu.property section = no control flow information Hardened: libruby.so.3.1.0: FAIL: property-note test because no .note.gnu.property section found Hardened: Rerun annocheck with --verbose to see more information on the tests. ``` The message `Hardened: libruby.so.3.1.0: FAIL: property-note test because no .note.gnu.property section found` is what I found in our internal test. For other FAIL messages, maybe it can be fixed by changing how to build. Asking a colleague, I was told that the `coroutine/*/Context.S` files such as [coroutine/x86/Context.S](https://github.com/ruby/ruby/blob/master/coroutine… cause the failure. Do you have any idea how to fix this? Thanks. * [1] https://sourceware.org/annobin/ * [2] You can see `man annocheck` or https://www.mankier.com/1/annocheck . ---Files-------------------------------- 0001-Add-.note.gnu.property-sections.patch (2.64 KB) 0001-Add-.note.gnu.property-sections.patch (3.69 KB) config-pie.log (11.4 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126393] [Ruby Feature#22245] Reduce Array#& cost when self is much shorter than the argument
by andrey.samsonov＠gmail.com (Andrey Samsonov) 11 Sep '26

11 Sep '26

Issue #22245 has been reported by andrey.samsonov(a)gmail.com (Andrey Samsonov). ---------------------------------------- Feature #22245: Reduce Array#& cost when self is much shorter than the argument https://bugs.ruby-lang.org/issues/22245 * Author: andrey.samsonov(a)gmail.com (Andrey Samsonov) * Status: Open ---------------------------------------- # Abstract For intersections of larger arrays, Ruby builds a temporary hash from the argument to `Array#&`. As a result, `short & long` can be slower and use much more temporary memory than `long & short`. Callers cannot always choose the cheaper order because `Array#&` preserves the objects and order of `self`. This proposal reduces that operand-order cost when `self` is much shorter, making performance less dependent on which result order the caller needs. In a local test, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. Benchmarks modeled on real call sites improved by about 1.7-2.7x. An unmodified Rails 8.1 Active Model benchmark improved by about 1.3x. `Array#intersection` uses the same C function and gets the same change. # Background When either array has more than 16 elements, Ruby uses a hash-based lookup and always builds the temporary hash from the argument. This creates a large cost difference between: ```ruby short & long long & short ``` The first expression hashes `long`. The second hashes `short`, but it can return elements in a different order. Some callers need the first expression because of that order. [Feature #17109] proposed removing the same operand-order cost by swapping the arrays. It was rejected because that changed the documented result order. This proposal instead preserves the objects and order from `self`. This proposal hashes `self` when it is at most half as long as the argument. It then scans the argument and returns matches in `self` order. For normal `#hash` and `#eql?` implementations, the result contains the same objects from `self`, in the same order, without duplicates. # Proposal ## Compatibility question May `Array#&` and `Array#intersection` choose which array to hash based on their lengths? The result stays the same for built-in values and custom equality methods where `#eql?` is an equivalence relation, equal elements have equal `#hash` values, and both methods are stable, have no side effects, and return normally. For stable, side-effect-free methods, both hash-based paths make the same number of `#hash` calls. The receiver, order, and number of `#eql?` calls can change. Mutation or exceptions can also change how many calls complete. The patch makes the RDoc direction-neutral. `Array#intersect?` has chosen the hash side by length since Ruby 3.1. This is relevant precedent, although `intersect?` returns only a boolean. This patch also preserves the objects and order from `self`. ## Implementation When `len(self) <= len(argument) / 2`, and the arrays use the hash-based path: 1. Build a hash from the distinct elements of `self`. 2. Keep their first positions in `self`. 3. Scan the argument and mark each match. 4. Return the marked elements in `self` order. Small arrays, near-equal arrays, and a long `self` with a short argument keep the current path. `Array#|` is not changed because its operand-order cost has a different cause. `Array#-` preserves repeated unmatched elements and needs a separate algorithm and compatibility analysis. ## Why start at 2x? The 2x threshold is an empirical starting point, not part of the API. Forced-threshold benchmarks gave mixed results below 2x. At 2x, all tested cases with distinct argument elements improved, with median gains of about 1.1-1.3x. I would welcome maintainer guidance on whether Ruby has an established method or relevant precedent for selecting thresholds like this. # Use cases - In Rails 8.1, `Array(only).map(&:to_s) & attribute_names` in `ActiveModel::Serialization#serializable_hash` filters a full attribute list with keys from the caller. - In Rails 8.1, Active Record collection replacement calls `intersection(new_target, original_target)`. The ordinary `HasManyAssociation` helper implements this as `a & b`; `HasManyThroughAssociation` uses a separate implementation. - Rails command lookup uses `lookups & namespaces.keys`. # Discussion ## Results The primary measurements ran on macOS arm64, with separate confirmation on Ubuntu 24.04 x86-64. Each comparison used the same Ruby commit with and without the patch. | Case | Benchmark case | Change | |---|---|---:| | ActiveModel shape, 6 and 50 strings | `attr-filter-6-and-50` | ~1.77x | | Collection replacement shape, 10 and 10,000 ids | `short-receiver-10-and-10k` | ~2.74x | On Linux, the same two shapes improved by 1.66x and 2.46x. Other id-list shapes moved by 1.11-1.23x there, but unchanged small-array cases moved by up to 1.16x in the same rounds, so I make no claim from those smaller deltas. With unmodified Rails 8.1 Active Model code, `ActiveModel#serializable_hash(only: 6 of 50 attributes)` improved from about 3.6 µs to about 2.8 µs per call. The control path without `only:` did not change. For memory, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. The scan still takes time proportional to the long array; the change removes the hash build from that array. The Rails 8.1.1 Lobsters workload entered the proposed branch 152 times across application boot and three iterations, mainly through Active Model serialization. Six alternating A/B batches found no detectable whole-workload change. ## Known trade-offs ### Arguments with many duplicates The threshold uses array lengths, not the number of distinct elements. A long argument with few distinct values can be cheap to hash. In tested cases at the exact `2x` threshold, throughput fell to about 0.64x on arm64 and about 0.90x on Linux. The mirrored case is slow on current Ruby: a short duplicate-heavy `self` with a long distinct argument improved by about 2.4x on arm64 and 1.6x on Linux with this patch. No choice based only on lengths can make both shapes faster. ### Hash collisions The new path makes hash quality on `self` more important; the current path makes hash quality on the argument more important. The worst-case complexity does not change, but the array that triggers it can change at the threshold. For example, 3,000 distinct elements in `self` with the same hash and a clean 6,000-element argument changed from about 0.5 ms to 63 ms. The reverse case changed from about 250 ms to 0.8 ms. `Array#intersect?` already makes the same trade when it chooses the shorter array. ### Custom `#hash` and `#eql?` Built-in integers, symbols, and strings cannot observe the call direction. User-defined methods can. The standard library provides an example with asymmetric `#eql?`: ```ruby require "delegate" string = "abc" delegator = SimpleDelegator.new(string) delegator.hash == string.hash # => true delegator.eql?(string) # => true string.eql?(delegator) # => false a = [delegator] + (1..20).map { |i| "x#{i}" } b = [string] + (1..100).map { |i| "y#{i}" } a & b # Current Ruby: [delegator], proposal: [] a.intersect?(b) # Current Ruby and proposal: false b & a # Current Ruby and proposal: [] ``` The proposal changes the first result and makes these three operations agree for this input. This agreement is not a compatibility guarantee. For values whose `#eql?` is symmetric, transitive, stable, and consistent with `#hash`, the result does not change. Logging, mutation, exceptions, object reachability, and GC timing can expose a different call order. These behaviors are not specified. ## Safety and tests Calls to user `#hash` and `#eql?` can mutate either array or run the GC. The candidate loop cannot write past the initial length of `self`. Candidate objects live in a Ruby array; the only raw buffer contains `bool` flags. Tests cover the `2x` boundary, both lookup paths, equality edge cases, mutation, and GC compaction. `ruby/test_array.rb` and `spec/ruby/core/array` pass. A randomized comparison with current Ruby produced the same results for normal values. Implementation: [one-commit fork branch](https://github.com/ruby/ruby/compare/master...kryzhovnik:array-and-…. It contains the change, the RDoc update, the tests, and the benchmarks. # See also - [ruby/ruby#14855](https://github.com/ruby/ruby/pull/14855) also chose an array by length, but did not preserve both the objects and order from `self`. - [Feature #15198] added `Array#intersect?`, which avoids materializing an intersection and can choose the hash side by length because it returns only a boolean. - [Feature #13884] added an existing size-based strategy choice for these methods. - [Bug #19622] led Ruby to document that these methods use both `#hash` and `#eql?`; it did not specify which operand receives the calls. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126356] [Ruby Feature#22238] String#tr to take a Hash for multi-character replacements
by byroot (Jean Boussier) 11 Sep '26

11 Sep '26

Issue #22238 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22238: String#tr to take a Hash for multi-character replacements https://bugs.ruby-lang.org/issues/22238 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- This is @matz's counter proposal to [Feature #22229] from the last dev-meeting > matz: I will counter-propose String#tr-with-hash style. ```ruby 'Hello </script>'.tr(">" => '\u003e', "<" => '\u003c', "&" => '\u0026') # matz: OK 'Hello </script>'.tr("abc" => 'ABC') # should raise an exception 'Hello </script>'.tr("abc" => 'ABC', "ab" => "XY") # should raise an exception "fée".tr("é" => "€") # it should work "Hello".tr("l" => "ABC", "o" => "XYZ") #=> "HeABCABCXYZ" "Hello".gsub(/./m) { hash[$&] || $& } # gsub equivalent ``` Notes: - Hash keys MUST be single characters (but can be multi-byte). - Values can be multiple characters. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:126661] [Ruby Bug#22307] Ruby::Box: assignments to C-backed global variables do not reach C
by hsbt (Hiroshi SHIBATA) 10 Sep '26

10 Sep '26

Issue #22307 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22307: Ruby::Box: assignments to C-backed global variables do not reach C https://bugs.ruby-lang.org/issues/22307 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, assigning a global variable backed by a C variable only updates a per-box table. The setter never runs and the interpreter keeps reading the C variable. This happens in the main box too. ``` $ RUBY_BOX=1 ruby --disable-gems -e '$/ = "!"; p "hello!".chomp, [$/, $-0]; $/ = 1; $-a = 1; p $stdout.equal?(STDOUT)' "hello!" ["!", "\n"] false ``` Without `RUBY_BOX`, `chomp` returns `"hello"`, `$-0` follows `$/`, and `$/ = 1` raises `TypeError`. 4.0.6 behaves the same. `gvar_use_box_tbl` (`variable.c:1025`) sends every variable in a user box, the main box included, through `box->gvar_tbl` unless it is marked `box_dynamic` or `box_ready`. The first read clones the getter's value into the table and later writes stay there. So `$/` and `$-0` get separate slots for one `rb_rs`, `$stdout` becomes a copy of `STDOUT`, and validating setters never run. So far this has been fixed one variable at a time with those two marks, in #21940 (`$_`), #21933 (`$~`) and #21991 (`$!`, `$@`). The open #22280, #22282 and #21867 have PRs that do the same. https://github.com/ruby/ruby/pull/18711 covers the rest in the main box by skipping the table for any variable whose setter is not the plain Ruby one, so the main box behaves like Ruby without boxes. Optional boxes keep the table, and `TestBox#test_global_variables` asserts that `$-0` and `$,` set in one box stay there. That holds only for Ruby code reading the variable. C code in every box reads the one C variable. ``` $ RUBY_BOX=1 ruby --disable-gems -e 'p Ruby::Box.new.eval(%q{$/ = "!"; ["hello!".chomp, $/, $-0]})' ["hello!", "!", "\n"] ``` I would like a decision on what these variables mean in an optional box. The first option keeps the box-local copy and accepts that the interpreter ignores it, which is where #18711 stops. The second shares them across all boxes like `box_dynamic` and changes `test_global_variables`. The third makes the C side per box, so every reader of `rb_rs` and the like looks it up through the current box. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126658] [Ruby Misc#22275] Ruby::Box support plan for RubyGems and Bundler
by hsbt (Hiroshi SHIBATA) 10 Sep '26

10 Sep '26

Issue #22275 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #22275: Ruby::Box support plan for RubyGems and Bundler https://bugs.ruby-lang.org/issues/22275 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- This is a tracking issue for making RubyGems and Bundler work with Ruby::Box, so that reviewers can see the whole picture and what to look at next in one place. ## Goal The goal is to realize [Feature #13847](https://bugs.ruby-lang.org/issues/13847) with Ruby::Box: loading a specific version of a gem, including default gems and C extensions, isolated from the copy that RubyGems/Bundler themselves use. Vendoring with namespace rewriting has been our workaround for pure-Ruby gems for years; Box removes that limitation. As a further step, we want RubyGems/Bundler to activate different gem versions per box, which enables the use cases already proposed around Box: gradual dependency upgrades, plugin systems with conflicting dependencies, and multiple applications in one process. ## First milestone Before designing such APIs, Box needs to leave experimental status. Our first milestone is that Rails and RubyGems/Bundler themselves work under `RUBY_BOX=1`, and that the ruby/rubygems repository runs its test suites with Box enabled continuously so we do not regress. ## Current status Both suites now run under `RUBY_BOX=1` with the pull requests below applied. The rubygems suite is at 0 failures ([ruby/rubygems#9826](https://github.com/ruby/rubygems/pull/9826), open). The bundler suite runs 3957 examples with box and non-box at parity; the single remaining failure is an unrelated upstream problem in a Rust extension test. Pending marks reference the unfixed core bugs below. ## Fixed ### ruby/ruby * [ruby/ruby#18218](https://github.com/ruby/ruby/pull/18218) / [ruby/ruby#18219](https://github.com/ruby/ruby/pull/18219) — `BUNDLER_SETUP` was consumed outside the main box ([Bug #22123](https://bugs.ruby-lang.org/issues/22123)). Shipped in 4.0.7. * [ruby/ruby#18509](https://github.com/ruby/ruby/pull/18509) — box-local extension DLLs on Windows were unloaded too early; now deferred. * [ruby/ruby#18534](https://github.com/ruby/ruby/pull/18534) — autoload-triggered require bypassed the box's `Kernel#require` ([Bug #21830](https://bugs.ruby-lang.org/issues/21830)). This alone took Rails from 500 on every request to fully working. * [ruby/ruby#18535](https://github.com/ruby/ruby/pull/18535) — with `--disable=gems`, modules prepended to `Kernel` in a user box ended up behind `Kernel` in the ancestry ([Bug #22270](https://bugs.ruby-lang.org/issues/22270)). * [ruby/ruby#18536](https://github.com/ruby/ruby/pull/18536) — the box extension copy embedded the full path in the temporary filename, exceeding NAME_MAX on deep paths, and the name was predictable ([Bug #22110](https://bugs.ruby-lang.org/issues/22110), [Bug #22271](https://bugs.ruby-lang.org/issues/22271)). * [ruby/ruby#18578](https://github.com/ruby/ruby/pull/18578) — the process-private directory added by the previous fix did not survive `fork`; a forked child removed it at exit ([Bug #22271](https://bugs.ruby-lang.org/issues/22271)). * [ruby/ruby#18575](https://github.com/ruby/ruby/pull/18575) — box resolution crashed on an IFUNC frame ([Bug #21977](https://bugs.ruby-lang.org/issues/21977)). Without this the bundler suite died with `[BUG]` and the dead workers cascaded into unrelated failures. * [ruby/ruby#18546](https://github.com/ruby/ruby/pull/18546) — `Symbol#to_proc` ignored box-local method definitions ([Bug #22015](https://bugs.ruby-lang.org/issues/22015), revived [ruby/ruby#16865](https://github.com/ruby/ruby/pull/16865)) Without this Bundler's spec harness died in rspec-core's `&:shellsplit` before running a single spec. ### ruby/rubygems * [ruby/rubygems#9809](https://github.com/ruby/rubygems/pull/9809) — Bundler evaluated gemspecs through `TOPLEVEL_BINDING`, which always belongs to the main box. It now uses a binding in the box Bundler is loaded in, so gemspecs resolve the right `Gem::Specification`. * [ruby/rubygems#9810](https://github.com/ruby/rubygems/pull/9810) — the `gem` CLI died under `RUBY_BOX=1`. `Marshal`-based deep copies could not resolve `Gem::` constants across boxes and were replaced with a plain deep dup, and `RUBY_BOX` is now stripped from extension build subprocesses, where mkmf `have_devel?` recurses until `SystemStackError` ([Bug #22283](https://bugs.ruby-lang.org/issues/22283)). Includes a CLI canary test that runs under `RUBY_BOX=1`. ## Open pull requests All review-requested to @tagomoris: * [ruby/ruby#18544](https://github.com/ruby/ruby/pull/18544) — `Marshal.load` resolves classes in the root box ([Bug #22090](https://bugs.ruby-lang.org/issues/22090)); an in-process round-trip of `Gem::Version` fails today. Under review. * [ruby/ruby#18574](https://github.com/ruby/ruby/pull/18574) — reassigning `$stdout`/`$stderr` is invisible to builtin writers ([Bug #21867](https://bugs.ruby-lang.org/issues/21867)), which breaks output-capturing test helpers everywhere. * [ruby/ruby#18577](https://github.com/ruby/ruby/pull/18577) — `$?` is uninitialized after `Kernel#system` and `IO.popen` ([Bug #22280](https://bugs.ruby-lang.org/issues/22280)). * [ruby/ruby#18579](https://github.com/ruby/ruby/pull/18579) — assignments to `$VERBOSE` and `$DEBUG` have no effect ([Bug #22282](https://bugs.ruby-lang.org/issues/22282)). * [ruby/ruby#18586](https://github.com/ruby/ruby/pull/18586) — `defined?` does not see global variables assigned in a box ([Bug #22283](https://bugs.ruby-lang.org/issues/22283)). This is why mkmf `have_devel?` never memoizes and recurses until the stack is exhausted, which is the "stack level too deep in extconf.rb" entry under Known issues in `doc/language/box.md`. ## Remaining problems without a fix * [Bug #22295](https://bugs.ruby-lang.org/issues/22295) — `ruby -r<gem>` and `RUBYOPT=-r<gem>` do not activate gems under Box. `require_libraries_in_main_box()` calls `rb_require_string()` directly, bypassing the RubyGems `Kernel#require` override. Item 3 of [Bug #21760](https://bugs.ruby-lang.org/issues/21760) reports the same gap in `Ruby::Box#require`. * [Misc #22296](https://bugs.ruby-lang.org/issues/22296) — stubbing a core class does not reach code already loaded in the root box, so existing test suites change behaviour under Box without failing loudly. `allow(File).to receive(:expand_path)` in the main box leaves `Pathname#expand_path` calling the real method. We hit this in the Bundler suite and scoped the stub as a workaround, but existing test code cannot be expected to know the rule. If this is intended box semantics, it should be documented as a known limitation, because rspec-mocks style stubbing of core classes is everywhere. ## Critical path [ruby/ruby#18544](https://github.com/ruby/ruby/pull/18544) is the last item on the critical path, because without it the artifice-based install specs fail wholesale. [ruby/ruby#18546](https://github.com/ruby/ruby/pull/18546) and [ruby/ruby#18575](https://github.com/ruby/ruby/pull/18575) were the other two and are now merged. [ruby/ruby#18574](https://github.com/ruby/ruby/pull/18574) and [ruby/ruby#18577](https://github.com/ruby/ruby/pull/18577) then let us drop most of the pending marks. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:126659] [Ruby Bug#22306] Ruby::Box: with_jit hooks do not reach existing boxes
by hsbt (Hiroshi SHIBATA) 10 Sep '26

10 Sep '26

Issue #22306 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22306: Ruby::Box: with_jit hooks do not reach existing boxes https://bugs.ruby-lang.org/issues/22306 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, enabling YJIT does not switch `Array#each`, `#map`, `#select` and `Integer#downto` to their Ruby implementations in the root and main boxes. Only boxes created later get them. ``` $ RUBY_BOX=1 ruby --yjit -e 'p Array.instance_method(:each).source_location, Ruby::Box.new.eval("Array.instance_method(:each).source_location")' nil ["<internal:array>", 219] ``` Without `RUBY_BOX` the first line is `["<internal:array>", 219]`. 4.0.6 gives the same output. `TestYJIT#test_yjit_option_uses_array_each_in_ruby` and `#test_yjit_enable_replaces_array_each` fail under `RUBY_BOX=1` for this reason. `with_jit` in `jit_hook.rb` registers its block while the builtins load in the master box, so the `undef` and `def` in it change only the master box. The hooks run after the root and main boxes exist, even with `--yjit` (`ruby.c:1877`). By then loading RubyGems has given both boxes their own copy of `Array`, as any cached method call on it does. Moving the hook call before the boxes are created would cover only `--yjit`, not `RubyVM::YJIT.enable`. I see two designs. The first runs the hooks in every existing box as well as the master box when a JIT is enabled. Each box would then check `rb_builtin_basic_definition_p` against its own definitions, so a box that patched `Array#each` keeps its patch. The blocks take their box from their environment, so this needs a way to run them with another box as the current one. The second stops redefining methods after boot. The Ruby implementations are defined at boot next to the C ones, before any box exists, and the JIT picks the Ruby one when it compiles a call. Nothing changes after boot, which fits a master box that runs no code. It does change how the JIT dispatches these methods and what `source_location` reports. `with_yjit` came with 478e0fc710b, when the Ruby `Array#each` from #20182 was limited to YJIT, and became `with_jit` for ZJIT in 2cd10de3309. Both predate Ruby::Box. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126653] [Ruby Bug#22305] Ruby::Box: statically linked prism loads in only one box
by hsbt (Hiroshi SHIBATA) 10 Sep '26

10 Sep '26

Issue #22305 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22305: Ruby::Box: statically linked prism loads in only one box https://bugs.ruby-lang.org/issues/22305 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, the statically linked prism can be required in only one box. The second box raises `LoadError`. ``` $ RUBY_BOX=1 ruby --disable-gems -e 'require "prism"; p Ruby::Box.new.eval(%q{require "prism"; Prism::VERSION})' lib/prism.rb:161:in 'Kernel#require': cannot load such file -- prism/prism (LoadError) ``` Swapping the order fails the same way. `--disable-gems` matters here. With a prism gem installed, each box dlopens its own copy of the gem's `prism.bundle` and the problem disappears, which makes it easy to miss. There is no `prism.so` file. `prism_init.c:8` registers the name `prism/prism.so` with `ruby_init_ext`, pointing at the `Init_prism` already linked into the interpreter, so `require "prism/prism"` behaves as if it had loaded an extension. That entry can be used only once (`load.c:1280`). The parser itself works in every box, but loading a gem that requires prism internally, such as error_highlight, is enough to break it in every box other than the one that loaded prism first. The obvious fixes do not hold. Running the init in every box leaves one set of C globals pointing at whichever box ran it last, so nodes parsed in the other box fail `is_a?(Prism::ProgramNode)`. That trades the `LoadError` for a silent type mismatch. Initializing prism before the boxes exist and marking the feature provided makes the `require "prism/prism"` inside an activated prism gem a no-op, so the gem's Ruby half binds to the interpreter's C half. The `ruby-lsp` benchmark fails on exactly that. I see three designs and would like one chosen. The first treats prism as an extension. The Ruby binding is built as its own shared object while the parser stays static, so each box dlopens its own copy the way it already does for other extensions. The same principle would also fix every extension under `--with-static-linked-ext`. It changes the build and needs symbol exports on Windows. The second treats it as part of the interpreter, like `String`. It is initialized once before the boxes and every box shares its classes. `defined?(Prism)` becomes true without a `require`, it adds 339 classes at boot, and a prism gem can no longer take over. The third changes Box instead. One way would be to share a statically linked extension across boxes like a builtin class without marking it provided, so that a prism gem can still take over, though I am not sure that fits where Box is heading. ## How prism came to ship this way #19741 mirrored YARP into ruby/ruby together with its Ruby API and registered the native part with `ruby_init_ext`. #19772 then moved toward mirroring only the C implementation and leaving the Ruby API to a bundled prism gem (#19772#note-29), and #19900 stated that prism would be a bundled gem with a native extension. The static registration from #19741 survived the rename, so prism ships as a default gem linked into the interpreter, and that registration is what fails here. The native extension #19900 described works in every box, and the first design comes down to it. The second design has a history of its own. Matz first approved a built-in `Ruby::Parser` that no gem could replace (#19772#note-9), and the same idea came back as a gem-independent `Ruby::Node` for `Proc#syntax_tree` (#21795#note-1). There Matz required that the parser that ran the program and the parser that returns the tree be the same (#21795#note-19), and the feature settled on the default gem prism for that. That is exactly the prism a second box cannot load, which also blocks the way #21795#note-38 suggested Box could eventually expose the interpreter's own parser. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125416] [Ruby Feature#22056] Add zero-copy String constructor backed by an arbitrary Ruby object
by himura467 (Akito Shitara) 10 Sep '26

10 Sep '26

Issue #22056 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22056: Add zero-copy String constructor backed by an arbitrary Ruby object https://bugs.ruby-lang.org/issues/22056 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ### Description Ruby has rich built-in functionality for working with byte sequences through `String`. Objects that manage their own byte buffers naturally want to expose their data through this interface. The straightforward approach is `rb_str_new()`, which copies the bytes: ``` c VALUE str = rb_str_new(str, len); ``` For large or frequently accessed buffers this copy is wasteful in both time and memory. One approach is to create a String that directly references the existing memory, with the GC keeping the owner alive for as long as the String is reachable. This avoids both the copy and the need for manual lifetime management. ### Existing APIs and their limitations | API | Memory behavior | | ---- | ---- | | `rb_str_new` / `rb_str_new_cstr` | Copies bytes; String owns the allocation | | `rb_str_new_shared` / `rb_str_new_frozen` | References another String's buffer; parent must be a String | | `rb_str_new_static` | References static (compile-time) storage; no lifetime management | `rb_str_new_static` avoids copying but is only safe for storage that lives forever. When memory is owned by a Ruby object, it is freed when that object is collected, and `rb_str_new_static` offers no way to express that dependency. The common workaround is to pin the owner via an instance variable: ``` c VALUE str = rb_str_new_static(str, len); rb_ivar_set(str, id_owner, owner); ``` This relies on undocumented GC behavior, incurs ivar table allocation overhead, and leaves lifetime management entirely to the caller. ### Proposal Add zero-copy String constructors that accept an explicit parent object. The proposed names are tentative and open for discussion (see below): ``` c VALUE rb_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_usascii_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_utf8_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_enc_str_new_external(const char *ptr, long len, rb_encoding *enc, VALUE parent); ``` `parent` can be any live Ruby object. The GC guarantees it is not collected before the returned String is. `ptr` must point into memory whose lifetime is tied to `parent`; no copy is made. ### Use cases *IO::Buffer#get_string* `IO::Buffer.for(string)` wraps a String's bytes in a READONLY EXTERNAL buffer. `IO::Buffer#get_string` now copies those bytes into a new String. With this API, the returned String can reference the source String directly: ``` c return rb_enc_str_new_external((const char *)base + offset, length, encoding, buffer->source); ``` The returned String holds a direct GC reference to the source String, so it remains valid even after the buffer is freed. *GLib::Bytes#to_s (ruby-gnome)* `GLib::Bytes` is an immutable, reference-counted byte buffer from GLib. The current [implementation](https://github.com/ruby-gnome/ruby-gnome/blob/1dad74d1a86f9… uses the ivar workaround: ``` c VALUE str = rb_str_new_static(data, size); rb_iv_set(str, "@bytes", self); ``` With the proposed API this becomes: ``` c return rb_str_new_external(data, size, self); ``` ### Open questions *Naming* The name `rb_str_new_external` is one option. Other candidates: * `rb_str_new_owned_by` / `rb_enc_str_new_owned_by` * `rb_str_new_pinned` / `rb_enc_str_new_pinned` * `rb_str_new_with_parent` / `rb_enc_str_new_with_parent` *Memory retention* When a String referencing a small slice of a large buffer remains reachable, the entire backing object is kept alive. This is the same concern that led Java to remove the shared-backing optimization from `String.substring()` in Java 7. The risk was also raised in the context of Ruby's own lazy substring proposal (#19315, https://bugs.ruby-lang.org/issues/19315#note-7) > I heard that Java stopped the shared substring technique 10 years ago (https://www.infoq.com/news/2013/12/Oracle-Tunes-Java-String/) because of the potential for memory leaks > > I don't disagree this proposal, but it would be nice if we could evaluate the effectiveness of this optimization. Whether the same concern applies to this proposal, and whether the API should offer a way to force an independent copy, is worth discussing. ### Proof of concept A prototype implementation is at: https://github.com/ruby/ruby/pull/16834 The implementation introduces a new flag on non-embedded strings and stores the parent reference in `RString.as.heap.aux.parent`. The GC mark phase pins embedded parent strings to prevent compaction from invalidating the raw pointer stored in the zero-copy child. -- https://bugs.ruby-lang.org/

7 28

[ruby-core:126651] [Ruby Feature#13677] Add more details to error "Name or service not known (SocketError)"
by akr (Akira Tanaka) 10 Sep '26

10 Sep '26

Issue #13677 has been updated by akr (Akira Tanaka). The current patch, which adds 'rb_str_catf(msg, " %+"PRIsVALUE, host);' is fine. ---------------------------------------- Feature #13677: Add more details to error "Name or service not known (SocketError)" https://bugs.ruby-lang.org/issues/13677#change-118909 * Author: dsbonev (Dimitar Bonev) * Status: Open ---------------------------------------- ruby version: `ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]` ruby script: ~~~ ruby require 'socket' TCPSocket.new 'nonexistent.example.com', 80 ~~~ Result: `getaddrinfo: Name or service not known (SocketError)` Expected: `getaddrinfo: Name or service not known for nonexistent.example.com (SocketError)` Why: This will make it easier to resolve errors of this kind by just looking at the logged messages. It is common for production and non-production (development, test) code to connect to different hosts which can produce errors due to wrong configuration. This change will make the ruby stdlib code more consistent as other methods already provide useful error information. Some examples: ~~~ ruby host = 'nonexistent.example.com'; port = 80 Resolv.getaddress host # => Resolv::ResolvError: no address for nonexistent.example.com Socket.getservbyname host # => SocketError: no such service nonexistent.example.com/tcp Net::HTTP.get Struct.new(:hostname, :port, :scheme).new(host, port, 'http') # => SocketError: Failed to open TCP connection to nonexistent.example.com:80 (getaddrinfo: Name or service not known) ~~~ If this issue will be resolved, please add any useful information to the error message in addition to the host. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126625] [Ruby Bug#22302] Prism and parse.y disagree on the `:line` event for a bare `nil` method body
by Eregon (Benoit Daloze) 10 Sep '26

10 Sep '26

Issue #22302 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22302: Prism and parse.y disagree on the `:line` event for a bare `nil` method body https://bugs.ruby-lang.org/issues/22302 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary The Prism compiler and the parse.y compiler produce a different set of `:line` trace points (line events) for a bare `nil` literal that is the value-producing body of a method. Prism emits a line event on the `nil`'s own line; parse.y does not. ```ruby def m nil end ``` - With `--parser=prism`, executing `m` (or setting a `TracePoint(:line)` / coverage / a debugger breakpoint) reports a line event on **line 2**. - With `--parser=parse.y`, there is **no** line event on line 2. ## Reproduction ### Compile-time line events ```ruby def line_events(iseq) events = iseq.trace_points.select { |_, event| event == :line }.map(&:first) iseq.each_child { |child| events.concat(line_events(child)) } events.sort end p line_events(RubyVM::InstructionSequence.compile("def m\n nil\nend\n")) ``` ``` $ ruby --parser=prism repro.rb [1, 2] $ ruby --parser=parse.y repro.rb [1] ``` ### Runtime `:line` events ```ruby seen = [] TracePoint.new(:line) { |tp| seen << tp.lineno if tp.path.end_with?("body.rb") }.enable do File.write("body.rb", "def m\n nil\nend\nm\n") load "./body.rb" end p seen.sort ``` ``` $ ruby --parser=prism rt.rb [1, 2, 4] $ ruby --parser=parse.y rt.rb [1, 4] ``` Under Prism a line event fires on line 2 (the `nil`) when `m` is called; under parse.y it does not. ## Instruction sequences The method body iseq differs only in the line attributed to the `putnil`, and whether it carries the line event (`[Li]`): ``` # --parser=parse.y 0000 putnil ( 1)[Ca] 0001 leave ( 3)[Re] # --parser=prism 0000 putnil ( 2)[LiCa] 0001 leave ( 3)[Re] ``` parse.y attributes the method's implicit-`nil` `putnil` to the definition line (1) with only the `RUBY_EVENT_CALL` flag, so no line event is emitted for line 2. Prism attributes the `putnil` to the `nil`'s own line (2) and emits a line event there. ## Scope of the difference The difference is specific to a bare `nil` in method (`def`/`defs`) tail position. Other cases behave the same under both parsers: - Other literals in the same position emit a line event under both parsers (`def m; true; end`, `def m; 1; end`, `def m; :a; end`, `def m; "s"; end`). - A bare `nil` at the top level, or as the body of a block or lambda, emits a line event under both parsers. - The failing shape also occurs when the tail `nil` is reached through the branch of a conditional, e.g. a method whose body is `if cond; nil; elsif ...; end`. The behavior is consistent across Ruby versions: parse.y has never emitted the line event for this case (checked back to 2.3), and Prism has emitted it since its compiler could be selected. This is a standing difference between the two compilers rather than a recent change; it only became visible by default when Prism became the default parser. ## Note on the cause This difference stems from void-expression elimination: parse.y treats the trailing `nil` as the method's implicit `nil` return and elides it (compiling a synthetic `putnil` with no line event), whereas Prism keeps it as an explicit value expression that carries a line event. It is not ideal that whether a `:line` event is emitted depends on whether an expression is eliminated as void, but that coupling is already the established behavior in both compilers — an unused bare literal in non-tail statement position (e.g. `1` or `:a` followed by another statement) likewise loses its line event under both parsers — so this is not unique to the case here, only the one place the two happen to disagree. ## Question Which behavior is intended — should a bare `nil` in method tail position emit a `:line` event or not? Currently the two parsers disagree, which affects `TracePoint(:line)`, line coverage, and debuggers depending on which parser compiled the code. ## Environment ``` ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] ``` Also reproduced on ruby 3.4.0 with `--parser=prism` / `--parser=parse.y`. (found in https://github.com/ruby/prism/pull/4223) -- https://bugs.ruby-lang.org/

1 3