From: "jhawthorn (John Hawthorn) via ruby-core" Date: 2026-08-25T06:23:51+00:00 Subject: [ruby-core:126490] [Ruby Bug#22242] SEGV in method dispatch (`vm_call_iseq_setup_kwparm_nokwarg` / `def_iseq_ptr`) on Ruby 4.0.6 — Rails CI Issue #22242 has been updated by jhawthorn (John Hawthorn). I've managed to reproduce this under rr locally through the Active Record test suite with `VM_CHECK_MODE` enabled. I don't have a more reliable reproduction yet or a fix. What the recording seems to show is that the ccs entries become orphaned in multi-ractor mode via a `vm_cc_table_dup_i` since that skips invalidated CMEs (a change I made in https://github.com/ruby/ruby/pull/15652, though that was to avoid a different crash) however that breaks our invariant that all "valid" CC's have their CME marked via the ccs table. So my change there is wrong (but also we shouldn't revert it because of what it fixed). This is also made more complicated because there's a latent bug in cc_is_active, where it always returns false, which . This should be "harmless" (bad for performance and CoW memory usage) because it simply clears the iseq's inline callcaches more often than it should, but is likely part of why this is hard to reproduce. I was planning to merge a fix for this into HEAD https://github.com/ruby/ruby/pull/18360 I do think 1da540aeaa1507af4c050bf8a6ee2802e65f9aac may fix this, but that's a tough one to backport. The weakref mechanism on Ruby HEAD makes that pretty cheap, but it's twice as expensive on 4.0 (which records the edges rather than the parent objects which have a weakref). Also, though it seems safe it was not the intended invalidation mechanism. I'd like to investigate more, a simpler reproduction would go a long way because it's very tricky to get call caches working correctly. ---------------------------------------- Bug #22242: SEGV in method dispatch (`vm_call_iseq_setup_kwparm_nokwarg` / `def_iseq_ptr`) on Ruby 4.0.6 ��� Rails CI https://bugs.ruby-lang.org/issues/22242#change-118650 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Recently Rails CI sometimes got SEGV. ## Steps to reproduce Run the Rails (rails/rails main branch) ActiveRecord test suite on Ruby 4.0.6, as Rails CI does. For example: ``` $ git clone https://github.com/rails/rails.git $ cd rails && bundle install $ cd activerecord $ bundle exec rake sqlite3_mem:test # also reproduced with trilogy:test and mysql2:test ``` The crash is intermittent (a small percentage of Rails CI runs) and the crashing test is different every time, so it may take many runs to reproduce. Rails CI log files for the five occurrences observed so far are attached, with Buildkite permalinks to the segfault in each job: - `rails_build_132123_activerecord-sqlite3-mem-4-dot-0.log` ��� https://buildkite.com/rails/rails/builds/132123#019fd767-de5d-4a26-8bd0-aa3778729237/L10156 - `rails_build_132137_activerecord-trilogy-4-dot-0-mysql-5-7.log` ��� https://buildkite.com/rails/rails/builds/132137#019fd855-0650-42f5-8771-a683619fc603/L5849 - `rails_build_132289_activerecord-mysql2-4-dot-0-mariadb.log` ��� https://buildkite.com/rails/rails/builds/132289#019fe7b7-0c81-43bf-8661-7a3f9fe01cc1/L4496 - `rails_build_132357_activerecord-sqlite3-mem-4-dot-0.log` ��� https://buildkite.com/rails/rails/builds/132357#019fefa9-5187-425b-9967-c10cabd5f4f2/L7898 - `rails_build_132357_activerecord-trilogy-4-dot-0-mysql-5-7.log` ��� https://buildkite.com/rails/rails/builds/132357#019fefa9-5188-4728-b712-b226999e30e6/L4778 ## Expected behavior It should always pass. ## Actual behavior The test process intermittently dies with `[BUG] Segmentation fault`. Every crash has the same signature: SEGV inside the interpreter's method dispatch while reading the iseq out of the callable method entry taken from an inline call cache ��� `def_iseq_ptr(vm_cc_cme(cc)->def)` ��� in either `vm_call_iseq_setup_kwparm_nokwarg` (vm_insnhelper.c:3116-3117) or `vm_call_iseq_setup_normal` (vm_insnhelper.c:3496): | Rails CI build | Job | Crashing test | Fault address | Crash frame | |---|---|---|---|---| | 132123 | activerecord sqlite3_mem (4.0) | NestedRelationScopingTest#test_nested_scoped_create | 0x17 | vm_call_iseq_setup_kwparm_nokwarg vm_insnhelper.c:3116 | | 132137 | activerecord trilogy (4.0) [mysql_5_7] | CompatibilityTest5_1#test_datetime_doesnt_set_precision_on_change_column | 0x08 | vm_call_iseq_setup_normal vm_insnhelper.c:3496 | | 132289 | activerecord mysql2 (4.0) [mariadb] | OptimisticLockingTest#test_polymorphic_destroy_with_dependencies_and_lock_version | 0x17b9 | vm_call_iseq_setup_kwparm_nokwarg vm_insnhelper.c:3117 | | 132357 | activerecord sqlite3_mem (4.0) | IntegrationTest#test_cache_version_format_is_not_too_precise | 0x1109 | vm_call_iseq_setup_kwparm_nokwarg vm_insnhelper.c:3117 | | 132357 | activerecord trilogy (4.0) [mysql_5_7] | ActiveRecord::ConnectionAdapters::ConnectionHandlersShardingDbTest#test_establish_connection_using_3_levels_config_with_shards_and_replica | 0x18 | vm_call_iseq_setup_kwparm_nokwarg vm_insnhelper.c:3116 | The crash-site frames of the C-level backtraces, showing that all five crashes are duplicates of the same bug (full crash dumps are in the attached log files): Build 132123, activerecord sqlite3_mem (4.0): ``` /usr/local/lib/libruby.so.4.0(def_iseq_ptr+0x0) [0x7fa976246636] /usr/src/ruby/vm_insnhelper.c:3116 /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_kwparm_nokwarg) /usr/src/ruby/vm_insnhelper.c:3116 /usr/local/lib/libruby.so.4.0(vm_sendish+0xb0) [0x7fa97625ecb5] /usr/src/ruby/vm_insnhelper.c:6134 /usr/local/lib/libruby.so.4.0(vm_exec_core) /usr/src/ruby/insns.def:904 ``` Build 132137, activerecord trilogy (4.0) [mysql_5_7]: ``` /usr/local/lib/libruby.so.4.0(def_iseq_ptr+0xd) [0x7ff68de8a350] /usr/src/ruby/vm_core.h:626 /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_normal) /usr/src/ruby/vm_insnhelper.c:3496 /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_normal_0start_0params_0locals) /usr/src/ruby/vm_call_iseq_optimized.inc:14 /usr/local/lib/libruby.so.4.0(vm_sendish+0xce) [0x7ff68de9692e] /usr/src/ruby/vm_insnhelper.c:6134 ``` Build 132289, activerecord mysql2 (4.0) [mariadb]: ``` /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_kwparm_nokwarg+0x2e) [0x7fb4fd53763e] /usr/src/ruby/vm_insnhelper.c:3117 /usr/local/lib/libruby.so.4.0(vm_sendish+0xb0) [0x7fb4fd54fcb5] /usr/src/ruby/vm_insnhelper.c:6134 /usr/local/lib/libruby.so.4.0(vm_exec_core) /usr/src/ruby/insns.def:904 /usr/local/lib/libruby.so.4.0(vm_exec_loop+0xa) [0x7fb4fd5565ca] /usr/src/ruby/vm.c:2825 ``` Build 132357, activerecord sqlite3_mem (4.0): ``` /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_kwparm_nokwarg+0x2e) [0x7ff26cc2163e] /usr/src/ruby/vm_insnhelper.c:3117 /usr/local/lib/libruby.so.4.0(vm_sendish+0xb0) [0x7ff26cc39cb5] /usr/src/ruby/vm_insnhelper.c:6134 /usr/local/lib/libruby.so.4.0(vm_exec_core) /usr/src/ruby/insns.def:904 /usr/local/lib/libruby.so.4.0(vm_exec_loop+0xa) [0x7ff26cc405ca] /usr/src/ruby/vm.c:2825 ``` Build 132357, activerecord trilogy (4.0) [mysql_5_7]: ``` /usr/local/lib/libruby.so.4.0(def_iseq_ptr+0x0) [0x7fa242c65636] /usr/src/ruby/vm_insnhelper.c:3116 /usr/local/lib/libruby.so.4.0(vm_call_iseq_setup_kwparm_nokwarg) /usr/src/ruby/vm_insnhelper.c:3116 /usr/local/lib/libruby.so.4.0(vm_sendish+0xb0) [0x7fa242c7dcb5] /usr/src/ruby/vm_insnhelper.c:6134 /usr/local/lib/libruby.so.4.0(vm_exec_core) /usr/src/ruby/insns.def:904 ``` ---Files-------------------------------- rails-ci-ruby406-segv-logs.zip (942 KB) rails_build_132611_activerecord-mysql2-4-dot-0.log.zip (314 KB) -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/