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

[ruby-core:126497] [Ruby Bug#22263] Subject: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to 98f0921f2b)
by yahonda (Yasuo Honda) 28 Aug '26

28 Aug '26

Issue #22263 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22263: Subject: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to 98f0921f2b) https://bugs.ruby-lang.org/issues/22263 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-25T14:03:04Z master 17026737cc) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### 1. First occurrence in Rails CI https://buildkite.com/rails/rails-nightly/builds/4651#01a016ac-eaf9-4a71-9f… (job "activemodel (master-debug)", 2026-08-18, ruby 4.1.0dev (2026-08-18T13:12:35Z master 6b719acc57) +PRISM [x86_64-linux]) Two Active Model tests ran a short-lived Ractor in the test process. A few seconds later, `RailtieTest` forked child processes (Active Support's fork-based test isolation), and the children failed while booting a Rails application. ### 2. Steps to reproduce A Rails checkout is required. Verified with Rails main 0f36bbf72c and the `rubylang/ruby:master` Docker image (ruby 4.1.0dev (2026-08-25T07:50:12Z master 753ace46fe)); it reproduces every run. ``` $ git clone https://github.com/rails/rails && cd rails && bundle install $ cd activemodel $ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb ``` ### 3. Expected behavior The forked child behaves like its parent: the Rails application boots and the child exits with status 0 (`child: #<Process::Status: pid NNN exit 0>`). The test pair reports 0 errors. ### 4. Actual behavior The forked child raises an exception during `require` and exits with status 1; the parent process is unaffected: ``` $ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb Source locally installed gems is ignoring #<Bundler::StubSpecification name=psych version=5.5.0 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=prism version=1.9.0 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.8.2 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.9.2 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=erb version=6.0.7 platform=ruby> because it is missing extensions Source locally installed gems is ignoring #<Bundler::StubSpecification name=date version=3.5.1 platform=ruby> because it is missing extensions Run options: --seed 20598 # Running: ............................................................E Error: RailtieTest#test_i18n_customize_full_message_defaults_to_false: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:36 E Error: RailtieTest#test_secure_password_min_cost_is_false_in_the_development_environment: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:22 E Error: RailtieTest#test_i18n_customize_full_message_can_be_disabled: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:42 E Error: RailtieTest#test_secure_password_min_cost_is_true_in_the_test_environment: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:29 E Error: RailtieTest#test_i18n_customize_full_message_can_be_enabled: NoMethodError: super: no superclass method 'require' for main /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config' /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config' test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup' test/cases/railtie_test.rb:15:in 'Class#initialize' test/cases/railtie_test.rb:15:in 'Class#new' test/cases/railtie_test.rb:15:in 'RailtieTest#setup' bin/test test/cases/railtie_test.rb:49 Finished in 0.088916s, 731.0243 runs/s, 820.9965 assertions/s. 65 runs, 73 assertions, 0 failures, 5 errors, 0 skips $ ``` ### 5. Bisect result ``` 98f0921f2b06bcc6435fe96a99da3a857ac10477 introduces this behavior. ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:125377] [Ruby Bug#22018] ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage
by byroot (Jean Boussier) 28 Aug '26

28 Aug '26

Issue #22018 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22018: ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage https://bugs.ruby-lang.org/issues/22018 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction: ```ruby require "coverage" File.write("/tmp/a.rb", <<~RUBY) module CoverableRaw def self.call "cover up" end end CoverableRaw.call RUBY Coverage.start require "/tmp/a.rb" p Coverage.result File.write("/tmp/b.rb", <<~RUBY) module Coverable def self.call "cover up" end end Coverable.call RUBY class RubyVM::InstructionSequence def self.load_iseq(path) compile_file(path) end end Coverage.start require "/tmp/b.rb" p Coverage.result ``` Expected: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {"/tmp/b.rb" => [1, 1, 1, nil, nil, nil, 1]} ``` Actual: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {} ``` Patch: https://github.com/ruby/ruby/pull/16805 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126539] [Ruby Bug#22278] `Coverage.line_stub` emits warnings found in source code
by Earlopain (Earlopain _) 28 Aug '26

28 Aug '26

Issue #22278 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22278: `Coverage.line_stub` emits warnings found in source code https://bugs.ruby-lang.org/issues/22278 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Coverage.line_stub` is implemented via `RubyVM::InstructionSequence.compile_file`. That emits all warnings found in the source code when `$VERBOSE = true`. I found this via `simplecov`. It can do coverage for compiled erb, and it also shows files that have never been used in tests via the aforementioned method. When that file is erb on disk, then trying to interpret it as ruby gives a plethora of warnings. Probably simplecov should not do that with erb in the first place, but that's another story. I started seeing this from 4.0.3 -> 4.0.4 so I guess it was because of https://bugs.ruby-lang.org/issues/22018 Here is a simple reproducer: ```rb require "coverage" require "tempfile" $VERBOSE = true Tempfile.open do |f| f.write(<<~RUBY) def foo x = 1 true end RUBY f.close Coverage.line_stub(f.path) end # $ ruby test.rb # /tmp/20260828-2866859-62r0kn:2: warning: assigned but unused variable - x ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125915] [Ruby Bug#22173] `Ractor.new { Fiber.current }.value` raises `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2`
by yahonda (Yasuo Honda) 28 Aug '26

28 Aug '26

Issue #22173 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22173: `Ractor.new { Fiber.current }.value` raises `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2` https://bugs.ruby-lang.org/issues/22173 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This issue is originally found at https://github.com/rails/rails/issues/57954 ### Steps to reproduce 1. Build ruby with `-DRUBY_DEBUG=1` enabled like ``` #!/bin/bash cd ${HOME}/src/github.com/ruby/ruby make clean make distclean make realclean ./autogen.sh ./configure --prefix="${HOME}/.local/share/mise/installs/ruby/trunk" cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" optflags="-O3 -fno-inline" --disable-install-doc make -j"$(getconf _NPROCESSORS_ONLN)" make install ``` 2. Run these one liners ``` ruby -ve 'Ractor.new { Fiber.current }.value' ``` ``` ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ``` ### Expected behavior Both of one liners should pass: ``` $ ruby -ve 'Ractor.new { Fiber.current }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. $ ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. ``` ### Actual behavior Both of them raise the `[BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2` assertion failures added through https://github.com/ruby/ruby/commit/af2471365fe ``` $ ruby -ve 'Ractor.new { Fiber.current }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. <OBJ_INFO:rb_ractor_confirm_belonging@ractor_core.h:329> 0x000078fa403213d0 fiber/Fiber -e:1: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] ... ``` ``` $ ruby -ve 'Fiber[:x] = Object.new; Ractor.new { Fiber[:x].class }.value' ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] -e:1: warning: Ractor API is experimental and may change in future versions of Ruby. <OBJ_INFO:rb_ractor_confirm_belonging@ractor_core.h:329> 0x00007e56dbe9dfa8 T_OBJECT/Object len:0 capa:2 ptr:0x00007e56dbe9dfb8 -e:1: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 4.1.0dev (2026-07-02T09:24:35Z master 7c69f93d53) +PRISM [x86_64-linux] ``` ---Files-------------------------------- 1.out (23.8 KB) 2.out (23.8 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:114645] [Ruby master Bug#19865] Segfault when calling user signal handlers during VM shutdown
by ivoanjo (Ivo Anjo) 27 Aug '26

27 Aug '26

Issue #19865 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19865: Segfault when calling user signal handlers during VM shutdown https://bugs.ruby-lang.org/issues/19865 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) . I've found this issue while investigating a [customer crash report](https://github.com/DataDog/dd-trace-rb/issues/2980). ### Background The original issue was found in a production app. A number of things need to be in play to cause it. The [`ruby-odbc`](https://rubygems.org/gems/ruby-odbc) gem provides a way of accessing databases through the ODBC API. It wraps a database connection as a Data object, with a free function that, prior to freeing the native resources, disconnects from the database if the connection was still active. Because disconnecting from the database is a blocking operation, the gem (reasonably, in my opinion), releases the global VM lock before disconnecting. The trigger for the crash is: 1. The app in question used puma, and puma installs a `Signal.trap('TERM')` 2. The database object was still connected when the app started to shut down 3. A VM shutdown starts... 4. Half-way through shutdown, the VM received a SIGTERM signal, and queued it for processing 5. The VM calls the free function on all objects 6. The ruby-odbc gem sees there's an active database connection, and tries to release the GVL to call the blocking disconnect 7. Before releasing the GVL, the VM checks for pending interruptions 8. The VM tries to run the Ruby-level signal handler method half-way through VM shutdown, when you can no longer run Ruby code 9. Segfault ### How to reproduce (Ruby version & script) I was able to reproduce on a minimal example on Ruby 3.2.2 (`ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]`) and recent master (`ruby 3.3.0dev (2023-08-17T07:30:01Z master d26b015e83) [x86_64-linux]`). I've put the test-case up on github as well <https://github.com/DataDog/signal-bug-testcase>, but here's the important bits: `signal-bug-testcase.rb`: ```ruby require 'signal_bug_testcase' Signal.trap("TERM") { puts "Hello, world" } FOO = SignalBugTestcase.new ``` `signal_bug_testcase.c`: ```ruby #include <ruby.h> #include <ruby/thread.h> #include <signal.h> #include <unistd.h> typedef struct { int dummy; } BugTestcase; void *test_nogvl(void *unused) { fprintf(stderr, "GVL released!\n"); return NULL; } static void bug_testcase_free(void* ptr) { fprintf(stderr, "Free getting called! Sending signal...\n"); kill(getpid(), SIGTERM); fprintf(stderr, "SIGTERM signal queued, trying to release GVL...\n"); rb_thread_call_without_gvl(test_nogvl, NULL, NULL, NULL); fprintf(stderr, "After releasing GVL!\n"); free(ptr); } const rb_data_type_t bug_testcase_data_type = { .wrap_struct_name = "SignalBugTestcase", .function = { NULL, bug_testcase_free, NULL }, .flags = RUBY_TYPED_FREE_IMMEDIATELY }; VALUE bug_testcase_alloc(VALUE klass) { BugTestcase* obj = calloc(1, sizeof(BugTestcase)); return TypedData_Make_Struct(klass, BugTestcase, &bug_testcase_data_type, obj); } void Init_signal_bug_testcase(void) { VALUE cBugTestcase = rb_define_class("SignalBugTestcase", rb_cObject); rb_define_alloc_func(cBugTestcase, bug_testcase_alloc); } ``` ### Expectation and result No segfault happens. Interestingly, on Ruby 2.7, the VM exits half-way through but doesn't always segfault, but running it a few times always triggers the issue. On 3.2+ it crashes every time for me. I suspect the right thing here is to no longer accept/try to run any Ruby-level signal handlers after VM shutdown starts. Here's what I see with this test-case: ``` $ bundle exec ruby lib/signal-bug-testcase.rb Free getting called! Sending signal... SIGTERM signal queued, trying to release GVL... lib/signal-bug-testcase.rb:3: [BUG] Segmentation fault at 0x0000000000000007 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :puts c:0002 p:0005 s:0006 e:000005 BLOCK lib/signal-bug-testcase.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0001a0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- lib/signal-bug-testcase.rb:3:in `block in <main>' lib/signal-bug-testcase.rb:3:in `puts' -- Machine register context ------------------------------------------------ RIP: 0x000070aa64cedbe7 RBP: 0x000070aa648e8fd0 RSP: 0x00007ffc5c057608 RAX: 0x0000000000004171 RBX: 0x00007ffc5c057630 RCX: 0x0000000000000001 RDX: 0x00007ffc5c057630 RDI: 0x0000000000000007 RSI: 0x0000000000004171 R8: 0x000000000000021b R9: 0x0000000000000000 R10: 0x000070aa63eff048 R11: 0x0000000000000000 R12: 0x000070aa648e8fd0 R13: 0x0000000000004171 R14: 0x0000000000000007 R15: 0x000070aa648e8ff0 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- ruby-3.2.2/lib/libruby.so.3.2(rb_print_backtrace+0xd) [0x70aa64d5bb5f] ruby-3.2.2/vm_dump.c:785 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_bugreport) ruby-3.2.2/vm_dump.c:1080 ruby-3.2.2/lib/libruby.so.3.2(rb_bug_for_fatal_signal+0xf4) [0x70aa64b52164] ruby-3.2.2/error.c:813 ruby-3.2.2/lib/libruby.so.3.2(sigsegv+0x4d) [0x70aa64cab0fd] ruby-3.2.2/signal.c:964 /lib/x86_64-linux-gnu/libc.so.6(0x70aa64642520) [0x70aa64642520] ruby-3.2.2/lib/libruby.so.3.2(hash_table_index+0x0) [0x70aa64cedbe7] ruby-3.2.2/symbol.h:72 ruby-3.2.2/lib/libruby.so.3.2(rb_id_table_lookup) ruby-3.2.2/id_table.c:230 ruby-3.2.2/lib/libruby.so.3.2(cached_callable_method_entry+0x24) [0x70aa64d356bb] ruby-3.2.2/vm_method.c:1295 ruby-3.2.2/lib/libruby.so.3.2(callable_method_entry_or_negative) ruby-3.2.2/vm_method.c:1365 ruby-3.2.2/lib/libruby.so.3.2(callable_method_entry) ruby-3.2.2/vm_method.c:1402 ruby-3.2.2/lib/libruby.so.3.2(rb_callable_method_entry) ruby-3.2.2/vm_method.c:1409 ruby-3.2.2/lib/libruby.so.3.2(gccct_method_search_slowpath+0x38) [0x70aa64d36258] ruby-3.2.2/vm_eval.c:434 ruby-3.2.2/lib/libruby.so.3.2(rb_call0+0x267) [0x70aa64d4e877] ruby-3.2.2/vm_eval.c:483 ruby-3.2.2/lib/libruby.so.3.2(rb_call+0x32) [0x70aa64d4f406] ruby-3.2.2/vm_eval.c:877 ruby-3.2.2/lib/libruby.so.3.2(rb_funcallv_kw) ruby-3.2.2/vm_eval.c:1074 ruby-3.2.2/lib/libruby.so.3.2(vm_call_cfunc_with_frame+0x127) [0x70aa64d30277] ruby-3.2.2/vm_insnhelper.c:3268 ruby-3.2.2/lib/libruby.so.3.2(vm_sendish+0x97) [0x70aa64d407a4] ruby-3.2.2/vm_insnhelper.c:5080 ruby-3.2.2/lib/libruby.so.3.2(vm_exec_core) ruby-3.2.2/insns.def:820 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_exec+0xd3) [0x70aa64d460d3] ruby-3.2.2/vm.c:2374 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_invoke_proc+0x5f) [0x70aa64d4bfcf] ruby-3.2.2/vm.c:1603 ruby-3.2.2/lib/libruby.so.3.2(vm_call0_body+0x5df) [0x70aa64d4c5cf] ruby-3.2.2/vm_eval.c:274 ruby-3.2.2/lib/libruby.so.3.2(vm_call0_cc+0x77) [0x70aa64d4e7e7] ruby-3.2.2/vm_eval.c:87 ruby-3.2.2/lib/libruby.so.3.2(rb_call0) ruby-3.2.2/vm_eval.c:551 ruby-3.2.2/lib/libruby.so.3.2(rb_call+0x32) [0x70aa64d4f406] ruby-3.2.2/vm_eval.c:877 ruby-3.2.2/lib/libruby.so.3.2(rb_funcallv_kw) ruby-3.2.2/vm_eval.c:1074 ruby-3.2.2/lib/libruby.so.3.2(rb_eval_cmd_kw+0x142) [0x70aa64d4f562] ruby-3.2.2/vm_eval.c:1923 ruby-3.2.2/lib/libruby.so.3.2(signal_exec+0xf6) [0x70aa64caae16] ruby-3.2.2/signal.c:1064 ruby-3.2.2/lib/libruby.so.3.2(rb_threadptr_execute_interrupts+0x36b) [0x70aa64cf7078] ruby-3.2.2/thread.c:2334 ruby-3.2.2/lib/libruby.so.3.2(rb_threadptr_execute_interrupts) ruby-3.2.2/thread.c:2291 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_check_ints+0xb) [0x70aa64cf7ac5] ruby-3.2.2/vm_core.h:1994 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_check_ints) ruby-3.2.2/vm_core.h:1985 ruby-3.2.2/lib/libruby.so.3.2(unblock_function_set) ruby-3.2.2/thread.c:320 ruby-3.2.2/lib/libruby.so.3.2(blocking_region_begin) ruby-3.2.2/thread.c:1485 ruby-3.2.2/lib/libruby.so.3.2(rb_nogvl+0xbf) [0x70aa64cf90cf] ruby-3.2.2/thread.c:1548 signal-bug-testcase-2/lib/signal_bug_testcase.so(fprintf+0x0) [0x70aa6518f299] ../../../../ext/signal_bug_testcase/signal_bug_testcase.c:17 signal-bug-testcase-2/lib/signal_bug_testcase.so(bug_testcase_free) ../../../../ext/signal_bug_testcase/signal_bug_testcase.c:18 ruby-3.2.2/lib/libruby.so.3.2(run_final+0xf) [0x70aa64b73172] ruby-3.2.2/gc.c:4388 ruby-3.2.2/lib/libruby.so.3.2(finalize_list) ruby-3.2.2/gc.c:4407 ruby-3.2.2/lib/libruby.so.3.2(finalize_deferred_heap_pages) ruby-3.2.2/gc.c:4436 ruby-3.2.2/lib/libruby.so.3.2(rb_objspace_call_finalizer+0x350) [0x70aa64b80d70] ruby-3.2.2/gc.c:4573 ruby-3.2.2/lib/libruby.so.3.2(rb_ec_finalize+0x2a) [0x70aa64b5d6d1] ruby-3.2.2/eval.c:168 ruby-3.2.2/lib/libruby.so.3.2(rb_ec_cleanup) ruby-3.2.2/eval.c:262 ruby-3.2.2/lib/libruby.so.3.2(ruby_run_node+0x9d) [0x70aa64b5d91d] ruby-3.2.2/eval.c:330 ruby-3.2.2/bin/ruby(rb_main+0x21) [0x5d5d1295f187] ./main.c:38 ruby-3.2.2/bin/ruby(main) ./main.c:57 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x80) [0x70aa64629d90] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x70aa64629e40] ../csu/libc-start.c:392 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:379 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x5d5d1295f1d5] ``` ---Files-------------------------------- signal-bug-testcase-main.zip (7.73 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126515] [Ruby Feature#15381] Let double splat call `to_h` implicitly
by sanjioh (Fabio Sangiovanni) 27 Aug '26

27 Aug '26

Issue #15381 has been updated by sanjioh (Fabio Sangiovanni). Hi, I’m bringing this up again, hoping for inclusion in 4.1. If not, it would be great to know whether this is something that could happen in the future or whether it’s too much of a breaking change at this point. Thanks! ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-118679 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126459] [Ruby Feature#22256] Replace missing/dtoa.c with a uscale-based algorithm. Faster, smaller footprint, and fixes a rounding error.
by AndrewDile (Andrew Dile) 27 Aug '26

27 Aug '26

Issue #22256 has been reported by AndrewDile (Andrew Dile). ---------------------------------------- Feature #22256: Replace missing/dtoa.c with a uscale-based algorithm. Faster, smaller footprint, and fixes a rounding error. https://bugs.ruby-lang.org/issues/22256 * Author: AndrewDile (Andrew Dile) * Status: Open ---------------------------------------- I'm proposing a replacement of `missing/dtoa.c` with a faster, leaner, more correct algorithm. I have [a PR](https://github.com/ruby/ruby/pull/18373) open as a proposed solution, which also provides more details to the origin of the algorithm and its performance compared to `missing/dtoa.c`. This would solve a few edge case rounding issues that currently happen during `Float#to_s`, and it would significantly increase the performance of `Float#to_s` and `String#to_f`, all while unifying both formatting (shortest-width and fixed-width) and parsing under one primitive. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126493] [Ruby Bug#22261] ruby-head builds have been failing on aarch64-linux CI in ruby/ruby-dev-builder
by tikkss (Tsutomu Katsube) 25 Aug '26

25 Aug '26

Issue #22261 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #22261: ruby-head builds have been failing on aarch64-linux CI in ruby/ruby-dev-builder https://bugs.ruby-lang.org/issues/22261 * Author: tikkss (Tsutomu Katsube) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The daily "CRuby Dev Builds" workflow in ruby/ruby-dev-builder has failed every day since 2026-08-07: * https://github.com/ruby/ruby-dev-builder/actions/workflows/build.yml Because of this, `ruby-version: head` currently installs a snapshot from 2026-08-05: * https://github.com/ruby/ruby-dev-builder/releases Only the `build (ubuntu-26.04-arm, head)` job fails, during `make test-all TESTS="-j4"`. All other platforms build and test successfully, but since one matrix job fails, the "Publish Release" step is skipped and no new release is published. This looks like a ruby master issue on aarch64-linux rather than a issue in ruby-dev-builder. For what it is worth, it does not seem to reproduce on the rubyci.org Ubuntu 26.04 aarch64 machines, which have been green for the same period: * https://logs.rubyci.org/ubuntu-arm/ruby-master/recent.html The most frequent failure (2026-08-13, 08-16, 08-22, 08-23, 08-24) is a crash in `TestEnumerator#test_lazy_chain_under_gc_compact_stress`: ``` test/ruby/test_enumerator.rb:869: [BUG] try to mark T_NONE object (obj: out-of-heap:0x0000e8d1b901d640, parent: 0x0000e8d1b937ff80 T_IMEMO/<fields> (embed) len:2 capa:20x0000e8d1d3eb0040 proc_entry/Object ) ruby 4.1.0dev (2026-08-24T18:44:40Z :detached: c4fdf07d44) +PRISM [aarch64-linux] ``` Full crash dumps are in the logs: * https://github.com/ruby/ruby-dev-builder/actions/runs/32767004006/job/97558… (2026-08-24, c4fdf07d44) * job-logsc4fdf07d44.txt * https://github.com/ruby/ruby-dev-builder/actions/runs/32592837360/job/97079… (2026-08-22, 774cc95fd4) * job-logs774cc95fd4.txt On other days (2026-08-07, 08-08, 08-21), `TestObjectSpace#test_finalizer_with_super` failed instead: the child process exits successfully but prints garbage bytes (e.g. `"\xC5w<"`) instead of `:ok`: * https://github.com/ruby/ruby-dev-builder/actions/runs/31211225131/job/92974… (2026-08-07, 3156d5adb4) * job-logs3156d5adb4.txt ---Files-------------------------------- job-logsc4fdf07d44.txt (276 KB) job-logs774cc95fd4.txt (340 KB) job-logs3156d5adb4.txt (281 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126496] [Ruby Misc#22262] OSS-Fuzz `fuzz_prism` target never calls `ruby_init()`, so Prism is not being fuzzed
by schecki (Tim Scheckenbach) 25 Aug '26

25 Aug '26

Issue #22262 has been reported by schecki (Tim Scheckenbach). ---------------------------------------- Misc #22262: OSS-Fuzz `fuzz_prism` target never calls `ruby_init()`, so Prism is not being fuzzed https://bugs.ruby-lang.org/issues/22262 * Author: schecki (Tim Scheckenbach) * Status: Open ---------------------------------------- The OSS-Fuzz fuzz target `fuzz_prism` crashes on every non-empty input before it reaches the parser, so Prism has never actually been fuzzed. The harness source lives in OSS-Fuzz (`projects/ruby/fuzz_prism.cpp`), not in this repository, but it is Ruby's fuzzing integration and one of the ten Ruby targets is producing nothing but false positives. Input (attached): ```ruby #!/usr/bin/ruby -w # warn_indent: true undef uI1y36L9!, uI1y36L9! ``` ``` ==1991560==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000558 ==1991560==The signal is caused by a READ memory access. SCARINESS: 10 (null-deref) #0 ruby_xcalloc_body /src/ruby/gc.c:5282 #1 ruby_xcalloc /src/ruby/gc.c:5276:34 #2 LLVMFuzzerTestOneInput /src/fuzz_prism.cpp:37:25 ``` `fuzz_prism.cpp:37` is `pm_arena_t *arena = pm_arena_new();`, the first statement after the `size == 0` guard. `pm_arena_new()` is `xcalloc(1, sizeof(pm_arena_t))` (`prism/arena.c`), and in a CRuby build `xcalloc` is `ruby_xcalloc`, which reaches `rb_gc_impl_calloc(rb_gc_get_objspace(), ...)`. `rb_gc_get_objspace()` ends up reading `GET_VM()->ractor.main_ractor`, but the harness never calls `ruby_init()`, so `ruby_current_vm_ptr` is `NULL` and the read lands at `offsetof(rb_vm_t, ractor.main_ractor)` = `0x558` — the faulting address above, confirmed by `rdi = 0x558` in the register dump. The attached input is irrelevant to the crash: `pm_arena_new()` runs before any byte of `data` is examined, so every file of one byte or more fails identically. A zero-byte file is the only input that survives, via the `size == 0` guard. This is not a regression. `fuzz_prism.cpp` has two commits — `97728d6` (`ruby: initial integration`, oss-fuzz#14312, 2025-11-19) and `51fea8a` (`ruby: fix build`, oss-fuzz#15217, 2026-03-26) — and neither added `ruby_init()`. `51fea8a` moved the harness onto Prism's arena API, which only relocated the crash: the previous code called `pm_parser_init`, which reaches `pm_constant_pool_init`, which also calls `xcalloc`. `fuzz_prism.cpp` is the only one of the ten targets in `projects/ruby` missing `ruby_init()`; the other nine all have it. Unsure if this is the correct place to report this issue, but I'm also happy to open the issue somewhere else. Found by the CISPA Fandango Team. ---Files-------------------------------- crash-00000289082f96f2c1a33d4217daceb834efb03c (66 Bytes) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125838] [Ruby Feature#22130] Add a new YARV instruction for a `String.new` fast path
by tenderlovemaking (Aaron Patterson) 25 Aug '26

25 Aug '26

Issue #22130 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #22130: Add a new YARV instruction for a `String.new` fast path https://bugs.ruby-lang.org/issues/22130 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- I would like to introduce a new YARV instruction, `opt_string_new`. It's similar to `opt_new`, but it is specialized for strings. Today, we [define the `new` method on `String`](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da4ab26/string.c#L12890). The reason we define the `new` method on `String` is because people can call `new` with a capacity like this: ```ruby s = String.new(capacity: 1234) ``` We want to pass the capacity to the GC so that we can ask the GC to possibly allocate a "right sized" object that includes the underlying string buffer. If we didn't implement `new`, then we would be forced to allocate a regular 40 byte slot _as well as_ a `malloc` buffer for the string. There are a few downsides to the current implementation. First, users can subclass `String` and expect the signature they define on `initialize` be the same signature that is expected for `new`. For example ```ruby class CoolString < String def initialize(is_cool:) @is_cool = is_cool super(encoding: "UTF-8") end end CoolString.new(is_cool: true) ``` In order to handle this, the `new` implementation on `String` [must check that the receiver is String, and if not, it forwards the call](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da…. The user can call `super` from `initialize`, and they expect the string to be setup in the normal fashion (setting the encoding, etc). That means that the implementation of `rb_str_s_new` is very similar to `rb_str_init` (we have a lot of duplicated code). The other down side is that since `new` can accept keyword arguments, we end up with an extra hash allocation when calling the C method. I would like to propose adding an `opt_string_new` instruction that does the "right sized allocation" and then calls `initialize` on the instance. For example, when we compile code like `String.new(capacity: 123)`, we can know where "capacity" will be stored on the stack at compile time. Since we have the capacity, we can emit an `opt_string_new` instruction that allocates the string and then delegates to `initialize` (which we'll rewrite in Ruby). To make this more concrete, here are the iseqs today: ``` ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG>, 13 0009 opt_send_without_block <calldata!mid:initialize, argc:1, kw:[#<Symbol:0x000000000086110c>], FCALL|KWARG> 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG> 0015 swap 0016 pop 0017 leave ``` Here is what I'm proposing: ``` > ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_string_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG>, 13, 0 0010 pop 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG> 0015 swap 0016 pop 0017 leave ``` I've made a WIP pull request here: https://github.com/ruby/ruby/pull/17482 Here are a few benchmark results comparing against Ruby's master branch. Interpreter + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new: 19.811M i/s (± 0.6%, GC 6.3%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new: 44.473M i/s (± 0.9%, GC 14.4%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 2.24 ± 0.02 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(capacity: 123): 10.179M i/s (± 1.1%, GC 17.7%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(capacity: 123): 35.924M i/s (± 0.4%, GC 20.2%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.53 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 8.282M i/s (± 2.5%, GC 12.0%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 7.770M i/s (± 1.6%, GC 2.7%) Summary ruby /Users/aaron/.rubies/arm64/master/bin/ruby ran 1.07 ± 0.03 times faster than ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ``` The first two cases easily win with this patch. Passing only an encoding may be slightly slower, but they are very close (and the allocations are decreased). Here are the same benchmarks but with YJIT enabled: YJIT + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new: 31.008M i/s (± 0.8%, GC 9.8%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new: 97.603M i/s (± 0.8%, GC 30.9%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.15 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 12.986M i/s (± 1.3%, GC 22.2%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 77.827M i/s (± 0.4%, GC 42.0%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 5.99 ± 0.08 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 9.909M i/s (± 0.5%, GC 13.9%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 11.916M i/s (± 0.7%, GC 3.8%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 1.20 ± 0.01 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` The first two benchmarks are much faster than the master branch, and the last benchmark is faster because I moved `initialize` to Ruby. I've implemented this in ZJIT too, but I'm not going to post the numbers because they are very similar to YJIT for this micro benchmark. -- https://bugs.ruby-lang.org/

6 14