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

[ruby-core:126737] [Ruby Bug#22321] Assertion Failed: rb_vm_search_method_slowpath:RB_TYPE_2_P(klass, RUBY_T_CLASS, RUBY_T_ICLASS): klass: T_MODULE
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 09 Oct '26

09 Oct '26

Issue #22321 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22321: Assertion Failed: rb_vm_search_method_slowpath:RB_TYPE_2_P(klass, RUBY_T_CLASS, RUBY_T_ICLASS): klass: T_MODULE https://bugs.ruby-lang.org/issues/22321 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following program: ```ruby def assert_equal(*a) = nil bug15629_m1 = Module.new do def foo; end end bug15629_m2 = Module.new do def foo; end end bug15629_c = Class.new do include bug15629_m1 include bug15629_m2 end o = bug15629_c.new m = o.method(:foo) sm = m.super_method assert_equal(sm, m.unbind.bind(o).super_method) begin ObjectSpace.each_object(sm.class).first(50).each(&:inspect); GC.start(full_mark: true, immediate_sweep: true); Marshal.load(Marshal.dump(sm)); rescue Exception; end # dataflow fusion ``` makes the interpreter report: ``` ../vm_insnhelper.c:2264: Assertion Failed: rb_vm_search_method_slowpath:RB_TYPE_2_P(klass, RUBY_T_CLASS, RUBY_T_ICLASS): klass: T_MODULE ruby 4.1.0dev (2026-09-15T05:36:12Z master 3296d5c99c) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:---- s:0019 e:000018 l:y b:0001 r:(nil) CFUNC :inspect c:0003 p:---- s:0016 e:000015 l:y b:0001 r:(nil) CFUNC :each c:0002 p:0087 s:0012 E:001198 l:n b:---- r:(nil) EVAL /tmp/test.rb:16 [FINISH] c:0001 p:0000 s:0003 E:001ed8 l:y b:---- r:(nil) DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/test.rb:16:in '<main>' /tmp/test.rb:16:in 'each' /tmp/test.rb:16:in 'inspect' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(___interceptor_backtrace) [0x56e7d13b671a] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_print_backtrace+0x14) [0x56e7d18914ea] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_dump.c:1113 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_vm_bugreport) /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../vm_dump.c:1479 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_assert_failure_detail+0x233) [0x56e7d1371b2b] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../error.c:1258 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_vm_search_method_slowpath+0x558) [0x56e7d17f1478] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_search_method_slowpath0+0x32) [0x56e7d17f2ca2] ../vm_insnhelper.c:2295 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(gccct_method_search_slowpath+0x4d) [0x56e7d184980d] ../vm_eval.c:419 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_funcallv_scope+0x1a4) [0x56e7d18280c4] ../vm_eval.c:1064 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_inspect+0x15) [0x56e7d15a2335] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../object.c:733 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(method_inspect+0x52b) [0x56e7d15c81ab] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../proc.c:4101 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_call0_body+0x100a) [0x56e7d18759ba] ../vm_eval.c:164 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_call0+0x4c5) [0x56e7d1878705] ../vm_eval.c:101 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_funcall_with_block_kw+0x14d) [0x56e7d1829b7d] ../vm_eval.c:896 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_yield_with_symbol+0x1ff) [0x56e7d187ce8f] ../vm_insnhelper.c:5291 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/b ``` To reproduce: ``` /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby --disable-gems --parser=parse.y /tmp/test.rb ``` Commit: ``` 3296d5c99ce005e4698fb27a405e01d766ad2647 ``` Build configuration: ``` ../configure --prefix=... CC=clang-18 cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" ``` Operating System: ``` Ubuntu 24.04 host, Docker ffe-ruby:latest ``` *This bug was found by [fusion-fuzz](https://github.com/fusion-fuzz/fusion-fuzz)* -- 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) 09 Oct '26

09 Oct '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/

3 6

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

09 Oct '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/

2 1

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

09 Oct '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/

4 6

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

09 Oct '26

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

3 2

[ruby-core:127027] [Ruby Bug#15599] Mixing autoload and require causes deadlock and incomplete definition.
by mame (Yusuke Endoh) 09 Oct '26

09 Oct '26

Issue #15599 has been updated by mame (Yusuke Endoh). Status changed from Closed to Open This issue is not fixed. The M:N thread scheduler seems to have only changed the timing. Adding `sleep` makes each result deterministic (confirmed on 3.3.8, 3.4.4, 4.0.2, and master). i) shows `[:a1]` ``` $ cat a.rb class A def a1() end end $ cat base.rb autoload :A, './a' t1 = Thread.new { p A.instance_methods(false) } t2 = Thread.new { sleep 0.1; require './a' } t1.join t2.join $ ruby base.rb [:a1] ``` ii) shows `[]` ``` $ cat a.rb class A sleep 0.2 def a1() end end $ cat base.rb autoload :A, './a' t1 = Thread.new { sleep 0.1; p A.instance_methods(false) } t2 = Thread.new { require './a' } t1.join t2.join $ ruby base.rb [] ``` iii) deadlocks ``` $ cat a.rb sleep 0.2 class A def a1() end end $ cat base.rb autoload :A, './a' t1 = Thread.new { sleep 0.1; p A.instance_methods(false) } t2 = Thread.new { require './a' } t1.join t2.join $ ruby base.rb base.rb:6:in 'Thread#join': No live threads left. Deadlock? (fatal) ``` The only difference among these is where `sleep` is inserted. Let me reopen this. ---------------------------------------- Bug #15599: Mixing autoload and require causes deadlock and incomplete definition. https://bugs.ruby-lang.org/issues/15599#change-119423 * Author: akr (Akira Tanaka) * Status: Open * ruby -v: ruby 2.7.0dev (2019-02-11 trunk 67049) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- I found that mixing autoload and require causes deadlock and incomplete definition. ``` % cat a.rb class A def a1() end end % cat base.rb autoload :A, './a' t1 = Thread.new { p A.instance_methods(false) } t2 = Thread.new { require './a' } t1.join t2.join % ruby base.rb Traceback (most recent call last): 1: from base.rb:6:in `<main>' base.rb:6:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000055cc6943fde0 main thread:0x000055cc6935f4b0 * #<Thread:0x000055cc6938f190 sleep_forever> rb_thread_t:0x000055cc6935f4b0 native:0x00007f58d256eb40 int:0 base.rb:6:in `join' base.rb:6:in `<main>' * #<Thread:0x000055cc6968cfc8@base.rb:3 sleep_forever> rb_thread_t:0x000055cc69736180 native:0x00007f58ce7b3700 int:0 mutex:0x000055cc6943fde0 cond:1 depended by: tb_thread_id:0x000055cc6935f4b0 /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:3:in `block in <main>' * #<Thread:0x000055cc6968ccd0@base.rb:4 sleep_forever> rb_thread_t:0x000055cc6943fde0 native:0x00007f58ce5b1700 int:0 /tmp/a/a.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:4:in `block in <main>' % ruby base.rb [:a1] % ruby base.rb [] ``` The last run which prints [] means incomplete definition of A which a1 method is not defined. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127025] [Ruby Bug#22422] MatchData#integer_at returns nil instead of 0 for captures without digits (Possible difference from ticket intention)
by zevblut (Zev Blut) 09 Oct '26

09 Oct '26

Issue #22422 has been reported by zevblut (Zev Blut). ---------------------------------------- Bug #22422: MatchData#integer_at returns nil instead of 0 for captures without digits (Possible difference from ticket intention) https://bugs.ruby-lang.org/issues/22422 * Author: zevblut (Zev Blut) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-07T17:29:37Z master 6203c21e58) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The implementation for Feature #21932 differs from what the desired spec says from the comments. I found this while implementing the feature for JRuby. Please confirm if we want to stay with how it is implemented or adjust to the comments. Here are the details: `MatchData#integer_at` returns `nil` for a capture that matched but contains no digits. Feature #21932 says it should behave like `$N&.to_i`, returning `0` there and `nil` only when the group did not match (note 7, with the reasons in note 9). The rdoc also says "`$~.integer_at(N)` is equivalent to `$N&.to_i`". ### Steps to reproduce ```ruby # Compare MatchData#integer_at with $N&.to_i, which Feature #21932 says it is equivalent to. [ ["2024", 10], ["12abc", 10], ["foo", 10], ["", 10], ["T", 10], ["_1", 10], ["0x", 0], ].each do |capture, base| m = /\A(.*)\z/.match(capture) printf "%-8p base %-2d integer_at: %-5p $N&.to_i: %p\n", capture, base, m.integer_at(1, base), m[1]&.to_i(base) end m = /(a)|b/.match("b") printf "%-17s integer_at: %-5p $N&.to_i: %p\n", "unmatched group", m.integer_at(1), m[1]&.to_i ``` ### Actual result ``` ruby 4.1.0dev (2026-10-07T17:29:37Z master 6203c21e58) +PRISM [arm64-darwin25] "2024" base 10 integer_at: 2024 $N&.to_i: 2024 "12abc" base 10 integer_at: 12 $N&.to_i: 12 "foo" base 10 integer_at: nil $N&.to_i: 0 "" base 10 integer_at: nil $N&.to_i: 0 "T" base 10 integer_at: nil $N&.to_i: 0 "_1" base 10 integer_at: nil $N&.to_i: 0 "0x" base 0 integer_at: nil $N&.to_i: 0 unmatched group integer_at: nil $N&.to_i: nil ``` ### Expected result Both columns match: `integer_at` returns `0` for `"foo"`, `""`, `"T"`, `"_1"` and `"0x"`, and `nil` only for the unmatched group. That is the behavior described in [#21932 note 7](https://bugs.ruby-lang.org/issues/21932#note-7) (`"foo"` → `0`, `""` → `0`). [Note 9](https://bugs.ruby-lang.org/issues/21932#note-9) gives the reason: `nil` is kept to tell an unmatched group apart from a matched `"0"`. ### Cause `match_integer_at` returns the result of `rb_int_parse_cstr` as is ([re.c#L3871-L3873](https://github.com/ruby/ruby/blob/6203c21e58e4c27a91a3336…) That result is `nil` when no digits were parsed. `String#to_i` uses the same parser, but `rb_str_convert_to_inum` turns that `nil` into `0` ([bignum.c#L4343-L4350](https://github.com/ruby/ruby/blob/6203c21e58e4c27a91a…) The implementation was written before note 7. The current behavior is also recorded in ruby/spec, in `core/matchdata/integer_at_spec.rb` ("returns nil on non-integer matches", `"T"` → `nil`). That example would need to change too. `test_match_integer_at` only checks an unmatched group, which is `nil` either way. If `nil` is the intended behavior after all, then the rdoc and #21932 should say so instead. ### Rdoc example Separately, one rdoc example has the wrong result: ```ruby /\d+/.match("011").integer_at(0) #=> 10 in the rdoc, but actually 11 ``` The examples after it (base 12 → `13`, base 0 → `9`) are correct. --- `integer_at` is new in 4.1, so it is not in the latest stable release (4.0.7). I tested on master at 6203c21e58, and `re.c` is unchanged in today's master (966eaa54c2). JRuby implemented `integer_at` to match CRuby's current behavior (https://github.com/jruby/jruby/pull/9767) and will follow whichever behavior is chosen here. ---Files-------------------------------- integer_at_repro.rb (479 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127021] [Ruby Bug#22420] `require "strscan"` no longer activates the default gem, so a newer installed strscan is ignored and later loaded twice
by ksss (Yuki Kurihara) 09 Oct '26

09 Oct '26

Issue #22420 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Bug #22420: `require "strscan"` no longer activates the default gem, so a newer installed strscan is ignored and later loaded twice https://bugs.ruby-lang.org/issues/22420 * Author: ksss (Yuki Kurihara) * 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 ---------------------------------------- Since Ruby 4.0.0, `require "strscan"` loads the default version from rubylibdir even when a newer strscan gem is installed, and does not activate the default gem. If the gem is activated later, its extension is loaded on top of the one already loaded. ## Reproduction ``` $ ruby -v ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin25] $ gem install strscan # 3.1.8, newer than the default 3.1.6 $ ruby -e 'require "strscan"; p StringScanner::Version; p Gem.loaded_specs["strscan"]&.version' "3.1.6" nil $ ruby -e 'require "strscan"; gem "strscan"; require "strscan"; p StringScanner::Version' .../gems/strscan-3.1.8/lib/strscan.bundle: warning: already initialized constant StringScanner::Version .../gems/strscan-3.1.8/lib/strscan.bundle: warning: already initialized constant StringScanner::Id "3.1.8" ``` The second case happens in practice when a gem depending on strscan (e.g. rouge) is required after strscan. ## Expected Same as Ruby 3.3: ``` $ ruby -e 'require "strscan"; p StringScanner::Version; p Gem.loaded_specs["strscan"]&.version' "3.1.8" #<Gem::Version "3.1.8"> $ ruby -e 'require "strscan"; gem "strscan"; require "strscan"; p StringScanner::Version' "3.1.8" ``` ## Cause The installed default gemspec has wrong `files`. It has `lib/lib/strscan/strscan.rb`, and lacks `strscan.bundle`: ``` $ ruby -e 'p Gem::Specification.load(Dir[Gem.default_specifications_dir + "/strscan-*.gemspec"][0]).files.grep_v(/\Adoc\//)' [".rdoc_options", "COPYING", "LICENSE.txt", "ext/strscan/extconf.rb", "ext/strscan/strscan.c", "lib/lib/strscan/strscan.rb"] ``` So `Gem.register_default_spec` maps no `strscan` feature to the default gem. Both come from `load_gemspec` in `tool/rbinstall.rb`: * It prepends `lib/` to every `.rb` entry that does not exist relative to the current directory. This is meant for the files collected from the build (relative to the gem's lib directory), but is also applied to the files listed by the gemspec itself (relative to the gem root), so they become `lib/lib/...`. * The gemspec is evaluated with `binding` of `load_gemspec`, and strscan.gemspec assigns a local variable `files`, which overwrites the argument holding the collected files. So `strscan.bundle` is dropped. `require "io/console"` is also no longer mapped to the default gem for the same reason. Other default gems (json, openssl, psych, date, ...) get `lib/lib/...` entries as well, though their main features are still mapped. Ruby 3.4 and earlier replaced `spec.files` with the collected files, so this is a regression from the changes to `load_gemspec` for 4.0 (7ce339244953a6c3add543854292c61e9f5bc14b, d6b40320b2cfecf9802e664a4869353d195fcc6d). -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126826] [Ruby Bug#22341] Class#superclass can crash the interpreter in debug build
by tekknolagi (Maxwell Bernstein) 08 Oct '26

08 Oct '26

Issue #22341 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Bug #22341: Class#superclass can crash the interpreter in debug build https://bugs.ruby-lang.org/issues/22341 * Author: tekknolagi (Maxwell Bernstein) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While implementing this in ZJIT, @nirvdrum reported, and I investigated, a potential interpreter crash: module M; end C = Class.allocate C.include M C.superclass In a debug build, this crashes: plum% ./build-dev/miniruby crash.rb ../object.c:2398: Assertion Failed: rb_class_superclass:!RCLASS_SUPER(klass) ruby 4.1.0dev (2026-09-22T14:09:58Z mb-class-superclass 05c0248e3a) +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 l:y b:0001 r:0x0 CFUNC :superclass c:0002 p:0027 s:0006 e:000005 l:n b:---- r:0x0 EVAL crash.rb:4 [FINISH] c:0001 p:0000 s:0003 E:001fc8 l:y b:---- r:0x0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- crash.rb:4:in '<main>' crash.rb:4:in 'superclass' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_print_backtrace+0x24) [0x100b210c4] /Users/emacs/Documents/code/ruby/build-dev/../vm_dump.c:1113 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_print_backtrace) (null):0 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_vm_bugreport+0x3ac) [0x100b21490] /Users/emacs/Documents/code/ruby/build-dev/../vm_dump.c:1479 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure_detail+0x138) [0x10079c6b4] /Users/emacs/Documents/code/ruby/build-dev/../error.c:1258 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure_detail+0x0) [0x10079c57c] /Users/emacs/Documents/code/ruby/build-dev/../error.c:1234 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure) (null):0 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_class_superclass+0x254) [0x1008b1d18] /Users/emacs/Documents/code/ruby/build-dev/../object.c:2398 /Users/emacs/Documents/code/ruby/build-dev/miniruby(ractor_safe_call_cfunc_0+0x30) [0x100b0a8bc] ../vm_insnhelper.c:3720 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_with_frame_+0x290) [0x100af8900] ../vm_insnhelper.c:3904 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_with_frame+0x6c) [0x100af8bfc] ../vm_insnhelper.c:3950 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_other+0x38c) [0x100af84d0] ../vm_insnhelper.c:3976 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc+0x128) [0x100aede50] ../vm_insnhelper.c:4058 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_method_each_type+0x200) [0x100aecf90] ../vm_insnhelper.c:4896 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_method+0xe8) [0x100aecba4] ../vm_insnhelper.c:5022 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_general+0x28) [0x100a9b1f8] ../vm_insnhelper.c:5066 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_sendish+0x708) [0x100ab4424] ../vm_insnhelper.c:6283 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_exec_core) ../insns.def:911 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_vm_exec+0x118) [0x100a9c92c] /Users/emacs/Documents/code/ruby/build-dev/../vm.c:2901 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_iseq_eval_main+0x34) [0x100adef20] /Users/emacs/Documents/code/ruby/build-dev/../vm.c:3254 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_ec_exec_node+0x100) [0x1007ac1f8] /Users/emacs/Documents/code/ruby/build-dev/../eval.c:300 /Users/emacs/Documents/code/ruby/build-dev/miniruby(ruby_run_node+0x94) [0x1007ac0ac] /Users/emacs/Documents/code/ruby/build-dev/../eval.c:338 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_main+0x40) [0x10067ca2c] /Users/emacs/Documents/code/ruby/build-dev/../main.c:42 /Users/emacs/Documents/code/ruby/build-dev/miniruby(main+0x70) [0x10067c9b8] /Users/emacs/Documents/code/ruby/build-dev/../main.c:62 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:127015] [Ruby Bug#22418] Regex counted repetition disagrees with expanded equivalent pattern
by robertmorelli (Robert Morelli) 08 Oct '26

08 Oct '26

Issue #22418 has been reported by robertmorelli (Robert Morelli). ---------------------------------------- Bug #22418: Regex counted repetition disagrees with expanded equivalent pattern https://bugs.ruby-lang.org/issues/22418 * Author: robertmorelli (Robert Morelli) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- repro: ```ruby /(?:u|\b){3}d/.match?("uud") # false /(?:u|\b)(?:u|\b)(?:u|\b)d/.match?("uud") # true ``` The counted repetition should be equivalent to duplicating the group but it is not. -- https://bugs.ruby-lang.org/

1 0