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

[ruby-core:126768] [Ruby Bug#22333] Assertion Failed: ary_resize_capa:RARRAY_LEN(ary) <= capacity
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 18 Sep '26

18 Sep '26

Issue #22333 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22333: Assertion Failed: ary_resize_capa:RARRAY_LEN(ary) <= capacity https://bugs.ruby-lang.org/issues/22333 * 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_raise(*a) = (yield rescue nil) MIN_SIZE = ENV.fetch('SMALL_ARRAY_MIN', 0).to_i MAX_SIZE = ENV.fetch('SMALL_ARRAY_MAX', 16).to_i ITERATIONS = ENV.fetch('SMALL_ARRAY_ITERATIONS', 100).to_i ARRAYS = (MIN_SIZE..MAX_SIZE).map do |size1| (MIN_SIZE..MAX_SIZE).map do |size2| end end ITERATIONS.times do ARRAYS.each do |group| group.each do |arr1, arr2| end end end assert_raise(FrozenError) { ARRAYS.instance_eval { initialize 3, 4 } } # dataflow fusion ``` makes the interpreter report: ``` ../array.c:423: Assertion Failed: ary_resize_capa:RARRAY_LEN(ary) <= capacity ruby 4.1.0dev (2026-09-15T05:36:12Z master 3296d5c99c) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0007 p:---- s:0027 e:000026 l:y b:0001 r:(nil) CFUNC :initialize c:0006 p:0007 s:0021 e:000020 l:n b:---- r:(nil) BLOCK /tmp/test.rb:15 [FINISH] c:0005 p:---- s:0018 e:000017 l:y b:0001 r:(nil) CFUNC :instance_eval c:0004 p:0005 s:0014 e:000013 l:n b:---- r:(nil) BLOCK /tmp/test.rb:15 c:0003 p:0002 s:0011 e:000010 l:y b:0001 r:(nil) METHOD /tmp/test.rb:1 c:0002 p:0069 s:0006 e:000005 l:n b:---- r:(nil) EVAL /tmp/test.rb:15 [FINISH] c:0001 p:0000 s:0003 E:001ed8 l:y b:---- r:(nil) DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/test.rb:15:in '<main>' /tmp/test.rb:1:in 'assert_raise' /tmp/test.rb:15:in 'block in <main>' /tmp/test.rb:15:in 'instance_eval' /tmp/test.rb:15:in 'block (2 levels) in <main>' /tmp/test.rb:15:in 'initialize' -- 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) [0x5e65f4ed571a] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_print_backtrace+0x14) [0x5e65f53b04ea] /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) [0x5e65f4e90b2b] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../error.c:1258 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_assert_failure_detail+0x0) [0x5e65f4e908f8] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../error.c:1234 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_assert_failure) (null):0 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(ary_resize_capa+0x4a5) [0x5e65f5403485] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../array.c:423 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(rb_ary_initialize+0x308) [0x5e65f540f948] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/ruby-src/build/../array.c:1181 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_call_cfunc_with_frame_+0x27b) [0x5e65f537f20b] ../vm_insnhelper.c:3904 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_call_method_each_type+0x24a) [0x5e65f53694ba] ../vm_insnhelper.c:4896 /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_call_method+0x39f) [0x5e65f5368c4f] /home/fuzz/WorkSpace/fusion-fuzz/projects/ruby/install/bin/ruby(vm_exec_core+0x113dc) [0x5 ``` 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/

2 1

[ruby-core:126530] [Ruby Bug#22273] Aliasing doesn't interact well with Module#prepend
by luke-gru (Luke Gruber) 18 Sep '26

18 Sep '26

Issue #22273 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22273: Aliasing doesn't interact well with Module#prepend https://bugs.ruby-lang.org/issues/22273 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, aliasing doesn't interact well with `Module#prepend` in my opinion. ### Example ```ruby module Kernel prepend(Module.new do def require(feature) puts "requiring feature (prepend): #{feature}" super end end) end module Kernel alias original_require require def require(feature) puts "requiring feature (alias): #{feature}" original_require(feature) end end require "set" ``` This produces this behavior: ``` requiring feature (prepend): set requiring feature (alias): set requiring feature (prepend): set ../ruby/test.rb:5:in 'require': super: no superclass method 'require' for main (NoMethodError) ``` I would expect this behavior: ``` requiring feature (prepend): set requiring feature (alias): set # Then, the original require would succeed ``` This has caused issues such as [22263](https://bugs.ruby-lang.org/issues/22263). ### Bug? As far as I know this is intentional behavior introduced in Ruby 2.0 [here](https://bugs.ruby-lang.org/issues/7842). There are even tests and specs that codify this behavior such as `test_prepend_super_in_alias` and `prepend_spec.rb`. Even though it's intentional, I don't believe it's well thought out. I'm interested in hearing arguments for and against the current behavior (with code examples, preferably). -- https://bugs.ruby-lang.org/

6 9

[ruby-core:126765] [Ruby Bug#22332] Ruby::Box: prelude is evaluated only in the master box, so pp and binding.irb load into it
by hsbt (Hiroshi SHIBATA) 18 Sep '26

18 Sep '26

Issue #22332 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22332: Ruby::Box: prelude is evaluated only in the master box, so pp and binding.irb load into it https://bugs.ruby-lang.org/issues/22332 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.1.0dev (2026-09-17T00:01:17Z master 3f6143715a) [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, `Kernel#pp` prints but leaves nothing behind in the box that called it. ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'pp({a: 1}); p $LOADED_FEATURES.grep(/pp\.rb/).size, defined?(PP)' {a: 1} 0 nil $ ruby --disable-gems -e 'pp({a: 1}); p $LOADED_FEATURES.grep(/pp\.rb/).size, defined?(PP)' {a: 1} 1 "constant" ``` Requiring it afterwards therefore loads the same file a second time, and it redefines its own methods: ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'pp({a: 1}); require "pp"' {a: 1} .../lib/ruby/4.1.0+4/pp.rb:412: warning: method redefined; discarding old pretty_print .../lib/ruby/4.1.0+4/pp.rb:412: warning: previous definition of pretty_print was here (and 20 more) ``` A box created before the call cannot see it either, while one created afterwards inherits it from the master box: ``` $ RUBY_BOX=1 ruby --disable-gems -W:no-experimental -e 'before = Ruby::Box.new; pp({a: 1}); after = Ruby::Box.new; p before.eval("defined?(PP)"), after.eval("defined?(PP)")' {a: 1} nil "constant" ``` `Binding#irb` fails outright, because its `rescue LoadError, Gem::LoadError` clause is evaluated where RubyGems is not loaded: ``` $ RUBY_BOX=1 ruby -W:no-experimental -e 'binding.irb' < /dev/null -e:1:in 'Binding#irb': uninitialized constant Binding::Gem (NameError) ``` Without a box the same command starts irb. `prelude.rb` is evaluated once in `rb_call_builtin_inits()` (`Init_builtin_prelude()`, `inits.c:114`), before the root and main boxes exist, so the box recorded on `Kernel#pp` and `Binding#irb` is the master box, and the `require` they run loads there. `gem_prelude` already avoids this: `rb_load_gem_prelude()` (`builtin.c:114`) runs for root and main in `Init_builtin_features()` and again for every new box (`box.c:435`). So the question is where prelude should be evaluated. Three shapes I can see: - load prelude per box the way gem_prelude already is (https://github.com/ruby/ruby/pull/18713) - keep the single evaluation and mark the prelude methods `Primitive.attr! :caller_user_box`, so only their `require` resolves in the caller's box; - make `require` called from a master-box method resolve in the caller's box in general, which needs care not to become local rebinding (#21362). Is there another shape you would prefer? Reproduced on master 3f6143715a and on released 4.0.7. Related to #22275 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126760] [Ruby Bug#22330] heap uaf from string.encode()
by danielchong (Daniel Chong) 18 Sep '26

18 Sep '26

Issue #22330 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22330: heap uaf from string.encode() https://bugs.ruby-lang.org/issues/22330 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0-dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, a heap UAF seems possible in string's encode function. PoC ``` s = "あ" * 4000 s.encode("US-ASCII", fallback: proc { |c| s.replace("Z" * (16 * 1024 * 1024)) "?" }) ``` ASAN output (truncated): ``` ERROR: AddressSanitizer: heap-use-after-free ... READ of size 1 #0 transcode_restartable0 transcode.c:592:36 (*in_p) #1 transcode_restartable transcode.c:828 #2 rb_transcoding_convert transcode.c:864 #3 trans_sweep transcode.c:1191 #4 rb_trans_conv transcode.c:1281 #5 rb_econv_convert0 transcode.c:1400 #6 rb_econv_convert transcode.c:1508 #7 transcode_loop transcode.c:2417 (goto resume -> rb_econv_convert) #8 str_transcode0 transcode.c:2877 #9 str_transcode transcode.c:2907 #10 str_encode transcode.c:2973 freed by thread T0 here: #15 proc_fallback transcode.c:2340 (rb_proc_call -> user code reallocs source) #16 transcode_loop_fallback_try transcode.c:2366 #18 transcode_loop transcode.c:2433 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126763] [Ruby Bug#22331] Ruby::Box: a box's top self lacks the top-level definition methods
by hsbt (Hiroshi SHIBATA) 18 Sep '26

18 Sep '26

Issue #22331 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22331: Ruby::Box: a box's top self lacks the top-level definition methods https://bugs.ruby-lang.org/issues/22331 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * ruby -v: ruby 4.1.0dev (2026-09-17T00:01:17Z master 3f6143715a) [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, loading a file into a box fails on `private`, `public`, `include`, `using`, `define_method` and `ruby2_keywords`. ```ruby # toplevel.rb private def hidden; end puts "loaded" ``` ``` $ RUBY_BOX=1 ruby -W:no-experimental -e 'Ruby::Box.new.load(File.expand_path("toplevel.rb"))' toplevel.rb:1:in '<top (required)>': undefined method 'private' for #<Object:0x000000012421c180> (NoMethodError) $ RUBY_BOX=1 ruby -W:no-experimental -e 'load(File.expand_path("toplevel.rb"), true)' toplevel.rb:1:in '<top (required)>': undefined method 'private' for #<Object:0x00000001204bc180> (NoMethodError) ``` Without a box the same wrapped load only warns. Asking the loaded file what it has shows the difference: ``` $ ruby -e 'load(File.expand_path("show.rb"), true)' [:define_method, :include, :private, :public, :ruby2_keywords, :using] $ RUBY_BOX=1 ruby -W:no-experimental -e 'Ruby::Box.new.load(File.expand_path("show.rb"))' [] ``` The six methods are defined during setup on the singleton class of `rb_vm_top_self()` (`eval.c:2311`, `vm_method.c:3737`, `proc.c:5477`), before the root box exists, so all six land on the master box's top self. `box_entry_initialize()` (`box.c:170`) then gives every other box a fresh object carrying only `to_s` and `inspect`, and `load_wrapping()` (`load.c:848`) clones the current box's one. Top level still sees the master box's object, so the gap shows only from a file loaded into a box. So the question is what a box's top self should be. Three shapes I can see: - give every box a clone of the master box's top self, and let root and main share the master's object itself (https://github.com/ruby/ruby/pull/18707) - define the six methods on each box's own top self when the box is created, the way https://github.com/ruby/ruby/pull/18713 loads the prelude per box; - let every box share the master box's top self, making `main` one object process-wide. They differ in whether a singleton method added to `main` in one box is visible in another. Is there another shape you would prefer? The same identity gap also breaks four autoload specs under a box. Reproduced on master 3f6143715a and on released 4.0.7. Related to #22275 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126758] [Ruby Feature#22329] Specify --disable-gem per Ruby Box
by tagomoris (Satoshi Tagomori) 17 Sep '26

17 Sep '26

Issue #22329 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #22329: Specify --disable-gem per Ruby Box https://bugs.ruby-lang.org/issues/22329 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Assignee: tagomoris (Satoshi Tagomori) * Target version: 4.1 ---------------------------------------- Currently user boxes loads gems listed in the gem_prelude.rb if those gems are enabled in the process-wide. There is just only way to disable gems in boxes: specify `--disable-gems` in the entire process. This proposes a new keyword argument on `Ruby::Box#new` to disable gems per box. This makes possible to create a simple, clean boxes if the box doesn't require RubyGems and other bundled gems. Boxes without RubyGems are still useful for loading small scripts, reducing security risks by keeping load_path clean&simple, etc. ``` # RubyGems is enabled in main Gem #=> Gem # Create a box without RubyGems box = Ruby::Box.new(disable_gems: true) box::Gem # NameError ``` The default value of `disable_gems` is `false. There may be two options to have keyword arguments: * have all of `disable_gems`, `error_highlight`, `did_you_mean`, `syntax_suggest` similar to the command line options * have only `disable_gems` to disable all of 4 gems IMO having only `disable_gems` looks enough because all of RubyGems/ErrorHightlight/DidYouMean/SyntaxSuggest bring the better developer experience. The single keyword argument `disable_gems` can explain well: "this box doesn't expect those developer-centric features". Another discussion point is how we should handle `Ruby::Box.new(disable_gems: false)` when the process-wide `--disable-gems` is specified. Options: * respect the process-wide selection and leave RubyGems an others are not loaded * try to load RubyGems and others only in the box I prefer the first option, but it's not a strong opinion. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126756] [Ruby Bug#22328] Should IO#wait_priority be deprecated and then removed?
by sampokuokkanen (Sampo Kuokkanen) 17 Sep '26

17 Sep '26

Issue #22328 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22328: Should IO#wait_priority be deprecated and then removed? https://bugs.ruby-lang.org/issues/22328 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #18655, IO#wait_readable, IO#wait_writable, IO#wait_priority, and IO#wait were moved from io/wait into core. However, in #18655 note 11, Matz wrote: > After the discussion, we will drop wait_priority, but others are accepted. https://bugs.ruby-lang.org/issues/18655#note-11 https://github.com/ruby/dev-meeting-log/blob/d16be491afb7f3c0d956a6445dcb17… IO#wait_priority is still present in core today. It does not seem to be used that much: https://github.com/search?type=code&q=.wait_priority+language%3ARuby&l=Ruby So my question is, should it be deprecated and removed? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126741] [Ruby Bug#22323] Incorrect nonnull contract changes rb_typeddata_inherited_p(NULL, NULL) behavior
by yqtian (Yongqiang Tian) 17 Sep '26

17 Sep '26

Issue #22323 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22323: Incorrect nonnull contract changes rb_typeddata_inherited_p(NULL, NULL) behavior https://bugs.ruby-lang.org/issues/22323 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-16T01:40:57Z :detached: e60ce574f0) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `rb_typeddata_inherited_p()` documents that both arguments may be `NULL`, and its implementation returns true for `(NULL, NULL)`. However, both the exported declaration and the inline implementation are marked with `RBIMPL_ATTR_NONNULL(())`, which tells GCC and Clang that all pointer arguments are nonnull. This contradictory contract can change observable behavior under optimization. ## Relevant code The declaration is annotated as follows: ```c RBIMPL_ATTR_NONNULL(()) /** * Checks for the domestic relationship between the two. * * ... * * You can pass NULL to both arguments, don't know what that means though. */ int rb_typeddata_inherited_p(const rb_data_type_t *child, const rb_data_type_t *parent); ``` The inline implementation has the same annotation: ```c RBIMPL_ATTR_NONNULL(()) static inline bool rbimpl_typeddata_inherited_p_inline(const rb_data_type_t *child, const rb_data_type_t *parent) { do { if (RB_LIKELY(child == parent)) return true; } while ((child = child->parent) != NULL); return false; } #define rb_typeddata_inherited_p rbimpl_typeddata_inherited_p_inline ``` Because the equality check occurs before `child` is dereferenced, `rb_typeddata_inherited_p(NULL, NULL)` returns true according to the implementation. The relevant header is: https://github.com/ruby/ruby/blob/e60ce574f0/include/ruby/internal/core/rty… ## Reproducer I reproduced the issue with the following minimal C extension: ```c #include <ruby.h> #include <stdint.h> static VALUE typeddata_null(VALUE self, VALUE use_nonnull) { const rb_data_type_t *type = RTEST(use_nonnull) ? (const rb_data_type_t *)(uintptr_t)1 : NULL; int inherited = rb_typeddata_inherited_p(type, type); /* * Returning 2 means the compiler selected the type != NULL branch. * When use_nonnull is false, the expected result is inherited == 1. */ return INT2NUM(type != NULL ? 2 : inherited); } void Init_typeddata_null(void) { VALUE module = rb_define_module("TypeddataNull"); rb_define_singleton_method(module, "check", typeddata_null, 1); } ``` With this `extconf.rb`: ```ruby require "mkmf" create_makefile("typeddata_null") ``` I built the extension with Clang 18 at `-O0` and `-O2`, then ran: ```sh ruby -I. -r./typeddata_null -e 'p TypeddataNull.check(false)' ``` The results were: ```text Clang 18 -O0: 1 Clang 18 -O2: 2 ``` The argument to `check()` is `false`, so `type` is `NULL` at runtime. The expected result is therefore `1`: the two pointers are equal and `rb_typeddata_inherited_p(NULL, NULL)` returns true. The value `2` is not a return value from `rb_typeddata_inherited_p()`. It is a marker showing that Clang selected the later `type != NULL` branch. The `nonnull` annotation allows Clang to assume that `type` cannot be null after it has been passed to the function, even though the documented and implemented `(NULL, NULL)` case was used. Clang 14 generated the same optimized control flow. GCC and Clang also emit `-Wnonnull` diagnostics when the two null arguments are written directly. ## Possible fix If `(NULL, NULL)` is intended to remain supported, I believe the incompatible `RBIMPL_ATTR_NONNULL(())` annotations should be removed from both the exported declaration and `rbimpl_typeddata_inherited_p_inline()`. Removing only the annotation from the exported declaration is not sufficient because extension calls are redirected to the annotated inline implementation by the macro. After removing both annotations, the Clang 18 `-O2` extension reports: ```text 1 ``` The complete patched Ruby tree also passes `make test`. Could you confirm whether `(NULL, NULL)` is an intended input for this function? If it is not intended, the documentation and the explicit equality behavior may instead need to be updated. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126537] [Ruby Bug#22276] alias in a module falls back to Object even in classes not inheriting from Object
by shugo (Shugo Maeda) 17 Sep '26

17 Sep '26

Issue #22276 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22276: alias in a module falls back to Object even in classes not inheriting from Object https://bugs.ruby-lang.org/issues/22276 * Author: shugo (Shugo Maeda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-28T07:43:16Z master 69b49ac7ae) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When `alias` (or `alias_method`) is used in a module and the method is not found in the module, `alias` searches the method from `Object`. So a module can alias a method of `Kernel` or `Object`, and the alias works even if the module is later included in a class that does not have `Object` and `Kernel` as ancestors: ```ruby module M alias foo puts public :foo end class X < BasicObject include ::M end X.new.foo("hello") #=> hello ``` `X` does not include `Kernel`, but `X.new.foo` calls `Kernel#puts`. This fallback comes from Ruby 1.8, where `Object` was the root class, so every class that includes a module always had `Object` and `Kernel` as ancestors. Since Ruby 1.9 introduced `BasicObject`, this is no longer true, but the fallback is unchanged. As discussed in #22273, a module should be able to alias only its own methods and its ancestors' methods, and `Object` is not an ancestor of a module. This behavior is intentional in the current implementation. There are tests for it (`test_alias_in_module` in test/ruby/test_alias.rb for #9663, and "accesses a method defined on Object from Kernel" in spec/ruby/core/module/alias_method_spec.rb), and the documentation of `Module#alias_method` has an example `module Mod; alias_method :orig_exit, :exit; end`. So code like `module M; alias orig_to_s to_s; end` exists, and simply raising `NameError` will break it. Possible fixes: 1. Remove the fallback and raise `NameError`. This breaks existing code. 2. Do not resolve the method at alias time. Instead, resolve it at call time from the ancestors of the receiver's class, like ZSUPER methods. Existing code that includes the module in a subclass of `Object` keeps working, and `X.new.foo` above raises `NoMethodError`. 3. Keep the current behavior and document it. I think 2 is the best choice for compatibility. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 17 Sep '26

17 Sep '26

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

3 4