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

[ruby-core:126860] [Ruby Bug#22384] Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0)
by sethuarun (Sethupathi Arunachalam) 25 Sep '26

25 Sep '26

Issue #22384 has been reported by sethuarun (Sethupathi Arunachalam). ---------------------------------------- Bug #22384: Regexp compile error in the 2nd+ branch of a top-level alternation leaks the parse tree (regression from #13332, Ruby 4.0) https://bugs.ruby-lang.org/issues/22384 * Author: sethuarun (Sethupathi Arunachalam) * 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 ---------------------------------------- **Affects:** ruby 4.0.6 and 4.0.7 (official docker images and a jemalloc-linked build), master (commit still present). **Not affected:** 3.4.6. **Repro (plain Ruby, no extensions):** ```ruby def rss_kb = File.read('/proc/self/status')[/VmRSS:\s+(\d+)/, 1].to_i GC.start; b = rss_kb 500_000.times { Regexp.new("a|b(c") rescue nil } # RegexpError in the 2nd branch GC.start; puts "#{rss_kb - b} KB" # 4.0.6/4.0.7: ~65500 KB (134 B per compile); 3.4.6: 0 500_000.times { Regexp.new("b(c") rescue nil } # same error, no alternation: 0 KB on both ``` Also leaks: "a|b|c(d" (3rd branch), "a|b)c(d". Does not leak: nested "(a|b(c)". **Why it matters:** `Regexp#to_s` (rb_reg_str_with_term, re.c) re-runs onig_new on the inner pattern of any regexp whose source starts with "(?flags:" and ends with ")" to decide whether the prefix can be dropped. For every regexp shaped `/(?:a|b)c(d)/` that inner pattern is "a|b)c(d", which hits this leak. Rails calls Regexp#to_s on every Regexp in config.filter_parameters for every request (ActiveSupport::ParameterFilter compile_filters!, one ParameterFilter per request), and Rails precompiles filter_parameters into exactly that shape, so a Rails 7.1+/8.x app with a Regexp filter leaks ~128 B per request per process on Ruby 4.0. Observed on production: +3.4 MB/h per puma worker, 145 MB per worker after 40 h (jemalloc profile stacks: rb_reg_str_with_term → onig_new → onig_parse_make_tree → parse_subexp → parse_branch → parse_exp). **Cause:** commit 35000ac2ed "Prevent double free for too big repetition quantifiers (#13332)", regparse.c parse_subexp(). Before it, the alternation list was assigned to `*top` immediately and the loop's error paths called `onig_node_free(node)`. After it, the list lives in the local `topnode` and both error paths call `onig_node_free(topnode)` only. That is right for the `fetch_token` failure (`node` was already linked into topnode by the previous iteration), but wrong for the `parse_branch` failure: parse_branch returns the partially built branch in `*top` (see its `*top = node_new_list(node, NULL)` before the loop) and that node is not yet linked into topnode, so it is never freed. **Fix:** ```diff r = parse_branch(&node, tok, term, src, end, env); if (r < 0) { + onig_node_free(node); onig_node_free(topnode); return r; } ``` (parse_branch's own error path frees only the element that failed and leaves the list in *top, as it did before #13332; the top-level `if (r < 0) { onig_node_free(node); return r; }` a few lines above already does the same for the first branch.) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126851] [Ruby Bug#22382] IO#write of a shareable String from multiple Ractors causes use-after-free
by jamescook83 (James Cook) 25 Sep '26

25 Sep '26

Issue #22382 has been reported by jamescook83 (James Cook). ---------------------------------------- Bug #22382: IO#write of a shareable String from multiple Ractors causes use-after-free https://bugs.ruby-lang.org/issues/22382 * Author: jamescook83 (James Cook) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When several Ractors `IO#write` the same shareable, heap-allocated (non-embedded) String at the same moment, Ruby frees the String's buffer while the String is still alive. A later GC sweep double-frees it and aborts. **Reproduction** ```ruby # frozen_string_literal: true require "tmpdir" dir = Dir.mktmpdir TRIES = 300 1.upto(TRIES) do |try| $stderr.puts "try #{try} of #{TRIES}" str = Ractor.make_shareable(Random.bytes(512 * 1024)) # Control: one prior write from a single Ractor prevents the crash. File.binwrite(File.join(dir, "first"), str) if ENV["WRITE_FIRST"] go = Process.clock_gettime(Process::CLOCK_MONOTONIC) + 0.02 12.times.map do |n| Ractor.new(str, File.join(dir, "w#{n}"), go) do |s, path, at| Thread.pass until Process.clock_gettime(Process::CLOCK_MONOTONIC) >= at # start together File.binwrite(path, s) end end.each(&:join) GC.start end puts "finished #{TRIES} tries without crashing" ``` ``` try 9 of 300 <internal:gc>:44: [BUG] Aborted at 0x000000018e37e5e8 ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin25] ... libruby.4.0.dylib(_rb_gc_impl_free+0x50) libruby.4.0.dylib(_rb_gc_obj_free+0x1e8) libruby.4.0.dylib(_gc_sweep_plane+0x150) ``` macOS reports the abort as `POINTER_BEING_FREED_WAS_NOT_ALLOCATED`. Crashes 5 runs out of 5. With `WRITE_FIRST=1` (each String written once, from one Ractor, before the race) it finishes without crashing. **Cause** The crash goes away when each String is written once from a single Ractor first (WRITE_FIRST=1), which points at rb_str_tmp_frozen_no_embed_acquire (io.c:2038): on a String's first write it hands the String's buffer to a new String and re-points the String at it (string.c:1573). The same function was changed for fstrings in #21671. A similar issue around fstrings was resolved in #21671. ---Files-------------------------------- ractor_shareable_write_repro.rb (704 Bytes) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125612] [Ruby Bug#22092] `Array#sum` takes slow path, does not perform compensated summation of Float elements when init argument is a Float
by georgeclaghorn (George Claghorn) 25 Sep '26

25 Sep '26

Issue #22092 has been reported by georgeclaghorn (George Claghorn). ---------------------------------------- Bug #22092: `Array#sum` takes slow path, does not perform compensated summation of Float elements when init argument is a Float https://bugs.ruby-lang.org/issues/22092 * Author: georgeclaghorn (George Claghorn) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` % time ruby -e 'puts Array.new(1_000_000_000, 0.1).sum' 100000000.0 ruby -e 'puts Array.new(1_000_000_000, 0.1).sum' 2.67s user 2.02s system 71% cpu 6.577 total % time ruby -e 'puts Array.new(1_000_000_000, 0.1).sum(0.0)' 99999998.74541782 ruby -e 'puts Array.new(1_000_000_000, 0.1).sum(0.0)' 22.72s user 1.80s system 96% cpu 25.332 total ``` Both the fast path and compensated summation are undocumented implementation details as far as I know, but this appears to be a possible oversight. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:126852] [Ruby Bug#22383] Fix inverted `STR_SHARED` check in `rb_str_tmp_frozen_release`
by rwstauner (Randy Stauner) 25 Sep '26

25 Sep '26

Issue #22383 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22383: Fix inverted `STR_SHARED` check in `rb_str_tmp_frozen_release` https://bugs.ruby-lang.org/issues/22383 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/commit/45a2c95d0f7184c9cd64ddd26699af31bea8675… mistakenly rewrote FL_TEST_RAW(orig, STR_SHARED) && !FL_TEST_RAW(orig, STR_TMPLOCK|RUBY_FL_FREEZE) as FL_TEST_RAW(orig, STR_SHARED | STR_TMPLOCK) == STR_TMPLOCK && !OBJ_FROZEN_RAW(orig) requiring orig to not be shared, the opposite of the original condition. orig always shares the buffer with tmp here, so the buffer was never given back and the string stayed shared until its next modification copied it. The next line of code then reads aux.shared from strings that are not shared, where the union holds aux.capa. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:126850] [Ruby Bug#22381] MatchData assigned to $~ is incorrectly reused
by jhawthorn (John Hawthorn) 24 Sep '26

24 Sep '26

Issue #22381 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22381: MatchData assigned to $~ is incorrectly reused https://bugs.ruby-lang.org/issues/22381 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby m = /a/.match("a").dup # dup a MatchData (has no "busy" flag set) $~ = m # assign to $~ /b/ =~ "b" # perform an p m # "b" on Ruby 4.0 (and 1.8-2.7, incorrect) # "a" on Ruby 3.0-3.4 (correct) ``` This is because the MATCH_BUSY flag isn't set correct and so the implicit match reuse (removed in #17507, re-added in #20652) mutates this escaped value -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126848] [Ruby Bug#22380] Ruby::Box: a GC while copying a class into a box crashes
by hsbt (Hiroshi SHIBATA) 24 Sep '26

24 Sep '26

Issue #22380 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22380: Ruby::Box: a GC while copying a class into a box crashes https://bugs.ruby-lang.org/issues/22380 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.0.7 (2026-09-22 revision 9aea6bb2f1) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- This is a backport request for the following crash: ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'GC.stress = true; module Enumerable; def m; end; end' -e:1: [BUG] try to mark T_NONE object (obj: 0x00000001042efe28 T_NONE/, parent: 0x000000010416dc08 T_MODULE/Module Enumerable) ``` Fixed on master by 44fff96b0bc and 18b6bfdb67e (https://github.com/ruby/ruby/pull/18842) Ruby 4.0.7 still crashes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126847] [Ruby Feature#22379] Remove prism mismatch warning from `#syntax_tree`
by Earlopain (Earlopain _) 24 Sep '26

24 Sep '26

Issue #22379 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #22379: Remove prism mismatch warning from `#syntax_tree` https://bugs.ruby-lang.org/issues/22379 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- #21795 added `#syntax_tree` for a few objects. Currently it is implemented in a way that uses the prism gem, using node_id. Because it is theoretically possible that node_ids from the internal cruby version of prism don't match with the node_ids from the installed prism gem, a warning is emitted when the two versions don't match: ```rb def x = nil pp method(:x).syntax_tree # => syntax_tree: a prism gem other than the default gem is loaded; the result may not correspond exactly to the compiled code # => @ DefNode (location: (1,0)-(1,11)) # ... ``` That this version-mismatch happens is basically a given. The vendored version in cruby will not be updated and is totally separate from a users gemfile. If a new version of prism is released, it will eventually end up in a users lockfile. Or users don't update prism while bumping to a cruby patch version that vendored a newer version of prism. If I see a warning, I assume that I have to make some change in the code to avoid it but there is nothing realistic for me to do, except to stop using the method alltogether. The warning is verbose-only. However it's good practise to run test suites with warnings enabled to keep up on deprecations, so even there it does not fit. I would like this warning to become documentation only for the above reasons. @eregon also suggested to only warn when we can prove that the node_id doesn't match. That should be possible as well, since we have the code location from the iseq and can check if the node we found via prism lines up. However, that doesn't guarantee that the contents of the node are also the same. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125919] [Ruby Bug#22174] Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity
by gil.desmarais (Gil Desmarais) 24 Sep '26

24 Sep '26

Issue #22174 has been reported by gil.desmarais (Gil Desmarais). ---------------------------------------- Bug #22174: Set operations (&, ^, collect!, flatten, classify, divide) do not preserve compare_by_identity https://bugs.ruby-lang.org/issues/22174 * Author: gil.desmarais (Gil Desmarais) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Since `Set` was transitioned to a C-level core class in Ruby 4.0, several operations that allocate new sets or partition subsets (`&`, `^`, `collect!`, `flatten`, `classify`, and `divide`) lost the `compare_by_identity` behavior for the receiver set or its subsets. * For `&`, `collect!`, `flatten`, `classify`, and `divide`, the resulting sets/subsets are allocated without propagating the `compare_by_identity` flag (returning `false` for `#compare_by_identity?`). * For `^` (XOR) with a generic `Enumerable`, the returned set has the flag set (via `dup`), but it allocates a temporary set `tmp` to hold the RHS elements without propagating the `compare_by_identity` flag. This causes the RHS elements to be deduplicated incorrectly using value equality instead of identity equality. A pull request has been opened with the fix and tests: https://github.com/ruby/ruby/pull/17633 ### Reproduction ```ruby require 'set' # 1. Intersection & s1 = Set.new.compare_by_identity s2 = Set.new s1 << "a" s2 << "a" puts "Intersection preserves compare_by_identity: #{(s1 & s2).compare_by_identity?}" # Expected: true # Actual: false # 2. XOR ^ (with duplicate objects by value on RHS) s_xor = Set.new.compare_by_identity x1 = +"x" x2 = +"x" result = s_xor ^ [x1, x2] puts "XOR with Enumerable preserves identity comparison: #{result.size == 2}" # Expected: true (size should be 2, because x1 and x2 are distinct objects) # Actual: false (size is 1) # 3. collect! / map! s_collect = Set.new(["a", "b"]).compare_by_identity s_collect.collect! { |x| x } puts "collect! preserves compare_by_identity: #{s_collect.compare_by_identity?}" # Expected: true # Actual: false # 4. flatten s_flat = Set.new([Set.new([1])]).compare_by_identity puts "flatten preserves compare_by_identity: #{s_flat.flatten.compare_by_identity?}" # Expected: true # Actual: false # 5. classify s_classify = Set.new(["a", "b"]).compare_by_identity classified = s_classify.classify { |x| x } puts "classify subsets preserve compare_by_identity: #{classified.values.all?(&:compare_by_identity?)}" # Expected: true # Actual: false # 6. divide s_divide = Set.new(["a", "b"]).compare_by_identity divided = s_divide.divide { |x| x } puts "divide subsets preserve compare_by_identity: #{divided.all?(&:compare_by_identity?)}" # Expected: true # Actual: false -- https://bugs.ruby-lang.org/

3 5

[ruby-core:126824] [Ruby Bug#22339] Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1
by Eregon (Benoit Daloze) 24 Sep '26

24 Sep '26

Issue #22339 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22339: Ruby::Box: crash / hang at VM shutdown with RUBY_FREE_AT_EXIT=1 https://bugs.ruby-lang.org/issues/22339 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- ## Summary With `RUBY_BOX=1` and `RUBY_FREE_AT_EXIT=1`, Ruby crashes or hangs while freeing boxes at VM shutdown. No user box needs to be created: the built-in boxes are enough. `box_entry_free()` walks `box->classext_cow_classes` at shutdown, but the objects in that table have already been freed by the shutdown sweep, so `free_classext_for_box()` sees a type that is no longer `T_CLASS`/`T_MODULE`/`T_ICLASS` and calls `rb_bug()`. Under ASAN the same teardown is caught one step earlier, as an iclass classext freed twice. ## Reproduction ```console $ RUBY_BOX=1 RUBY_FREE_AT_EXIT=1 ruby -e '' ``` Either environment variable alone is fine; only the combination fails. ## Observed behaviour `ruby 4.1.0dev (2026-09-21T14:42:24Z master 41e04ff507) +PRISM [arm64-darwin25]` hangs, spinning at 99% CPU. `sample(1)` of the main thread: ``` rb_ec_cleanup rb_objspace_call_finalizer rb_gc_obj_free box_entry_free (box.c, st_foreach over classext_cow_classes) st_general_foreach free_classext_for_box rb_bug ("Invalid type of object in classext_cow_classes: %s") rb_bug_without_die_internal rb_source_location_cstr _sigtramp <- SIGSEGV while printing the bug report sigsegv rb_bug_for_fatal_signal rb_source_location_cstr rb_iseq_path <- loops here forever ``` `ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [aarch64-linux]` (docker `ruby:4.0.7-slim-trixie`) dies with SIGSEGV (exit 139, core dumped) instead of hanging. The offending branch is in `free_classext_for_box()`: ```c if (RB_TYPE_P(obj, T_CLASS) || RB_TYPE_P(obj, T_MODULE)) { ... } else if (RB_TYPE_P(obj, T_ICLASS)) { ... } else { rb_bug("Invalid type of object in classext_cow_classes: %s", rb_type_str(BUILTIN_TYPE(obj))); } ``` ## ASAN evidence A Linux ASAN build of master reports a use-after-free in the same shutdown teardown, where the same `id_table` is freed twice through the identical call path: ``` ERROR: AddressSanitizer: heap-use-after-free, READ of size 8 #0 rb_id_table_free id_table.c:112:16 #1 rb_iclass_classext_free class.c:128:9 #2 rb_class_classext_foreach class.c:460:5 #3 rb_gc_obj_free gc.c:1402:9 #4 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #5 rb_objspace_call_finalizer gc.c:1739:5 #6 rb_ec_finalize eval.c:177:5 #7 rb_ec_cleanup eval.c:268:5 freed by thread T0 here: #0 free #1 rb_gc_impl_free gc/default/default.c:8285:9 #2 rb_iclass_classext_free class.c:128:9 #3 rb_class_classext_foreach class.c:460:5 #4 rb_gc_obj_free gc.c:1402:9 #5 rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3087:25 #6 rb_objspace_call_finalizer gc.c:1739:5 ``` That build additionally had a user box created before exit; the `rb_bug` reproduction above does not need one. ## Affected versions Same one-liner on each build: | build | result | | --- | --- | | master `41e04ff507`, arm64-darwin25 | hang (99% CPU) | | 4.0.7, 4.0.6, 4.0.3 (ruby-build), arm64-darwin25 | hang (99% CPU) | | 4.0.7 linux (`ruby:4.0.7-slim-trixie`, `ruby:4.0.7-slim-bookworm`) | SIGSEGV | | 4.0.6 linux (`ruby:4.0.6-slim-trixie`) | SIGSEGV | | 4.0.5, 4.0.3, 4.0.2, 4.0.1 linux (`ruby:4.0.x-slim`, `-slim-trixie`) | exits 0 | The base image makes no difference (bookworm and trixie behave the same), so this is the Ruby build rather than the distribution. Since the underlying defect is a use-after-free, the rows that exit 0 are presumably latent rather than unaffected: whether the freed object still reads back as a class depends on allocator reuse. ## Possibly a separate issue Once `rb_bug()` is reached at this point in shutdown, the bug reporter itself crashes in `rb_source_location_cstr()`, and the fatal signal handler re-enters the same function, so the process never terminates. A `rb_bug()` this late should still be able to abort. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126779] [Ruby Bug#22335] Stack corruption with >31 keyword args and refined Integer#==
by eapache_opslevel (Evan Huus) 23 Sep '26

23 Sep '26

Issue #22335 has been reported by eapache_opslevel (Evan Huus). ---------------------------------------- Bug #22335: Stack corruption with >31 keyword args and refined Integer#== https://bugs.ruby-lang.org/issues/22335 * Author: eapache_opslevel (Evan Huus) * Status: Open * ruby -v: 4.0.7 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is a messy one that originally surfaced as a flaky test in our Rails app, and required a lot of AI-assisted debugging to track down. This bug appears in the latest 4.0.7, though all of the original investigation was done against 3.3.11. If you have: - a method that takes only keyword args - has >31 keyword args - has a call-time-evaluated default value (e.g. `{}`) at argument index >31 - running in a Ruby process that has refined `Integer#==` at any point Then you get inconsistent stack corruption depending on your process's hash salt. The mechanism is nasty: - In a method with only keyword args, `vm_call_iseq_setup_kwparm_kwarg()` call `args_setup_kw_parameters()` with `klocals = argv + kw_param->bits_start - kw_param->num`, i.e. **above `cfp->sp`**, without first extending `cfp->sp` over those locals - `args_setup_kw_parameters()` uses a full hash, keyed by integer, for arguments beyond index 31 - When `args_setup_kw_parameters()` sets a key in that hash, and that key collides with another (not uncommon for a tiny hash, but still salt-dependent), it triggers an integer comparison - The refinement on `Integer#==` prevents that comparison from taking the fast path and turns it into a real C frame - Which gets pushed onto the stack, when the stack pointer hasn't been extended - Thus overwriting the other args and producing garbage The net effect is that the called method sees garbage values for the overwritten arguments. I've attached a reproducing script, which is unfortunately complex, as it needs to do some work to intentionally hit the correct hash collision depending on the process's salt. A simpler static version doesn't reproduce reliably enough to be useful. Even this version will occasionally get a hash salt with no collisions and fail to reproduce, though that seems pretty rare on my machine. ---Files-------------------------------- repro.rb (1.51 KB) -- https://bugs.ruby-lang.org/

3 3