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

[ruby-core:126374] [Ruby Bug#22242] laky SEGV in method dispatch (`vm_call_iseq_setup_kwparm_nokwarg` / `def_iseq_ptr`) on Ruby 4.0.6 — Rails CI
by yahonda (Yasuo Honda) 25 Aug '26

25 Aug '26

Issue #22242 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22242: laky 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 * 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-aa3… - `rails_build_132137_activerecord-trilogy-4-dot-0-mysql-5-7.log` — https://buildkite.com/rails/rails/builds/132137#019fd855-0650-42f5-8771-a68… - `rails_build_132289_activerecord-mysql2-4-dot-0-mariadb.log` — https://buildkite.com/rails/rails/builds/132289#019fe7b7-0c81-43bf-8661-7a3… - `rails_build_132357_activerecord-sqlite3-mem-4-dot-0.log` — https://buildkite.com/rails/rails/builds/132357#019fefa9-5187-425b-9967-c10… - `rails_build_132357_activerecord-trilogy-4-dot-0-mysql-5-7.log` — https://buildkite.com/rails/rails/builds/132357#019fefa9-5188-4728-b712-b22… ## 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) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:126488] [Ruby Feature#13847] Gem activated problem for default gems
by hsbt (Hiroshi SHIBATA) 25 Aug '26

25 Aug '26

Issue #13847 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed This can be addressed by Ruby::Box [Feature #21311], which loads code, including C extensions, into an isolated space with its own constants and loaded features. That resolves the concerns raised in 2017 about shared library conflicts and $LOADED_FEATURES ordering. Box is still experimental in Ruby 4.0. Box support in RubyGems/Bundler is already listed as a TODO, and we will work out its design and move it forward there, so I will close this ticket. ---------------------------------------- Feature #13847: Gem activated problem for default gems https://bugs.ruby-lang.org/issues/13847#change-118647 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- If you try to use some default gems with a fixed version using Bundler, there are cases where the current RubyGems/Bundler/Ruby specification can not be used with the version specified by the user. For example ``` $ ruby -v ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin17] $ gem list | grep openssl openssl (2.0.5, 2.0.4, default: 2.0.3) ``` In the environment such as ```require 'openssl'```, the version that is activated when openssl is searched with openssl is the version found first, ie 2.0.5. ``` $ ruby -ropenssl -e 'p OpenSSL::VERSION' "2.0.5" ``` At this time, for example, suppose the user really wants to use openssl 2.0.4 and wrote the following Gemfile. ``` > cat Gemfile # frozen_string_literal: true source "https://rubygems.org" gem 'openssl', '2.0.4' ``` Unfortunately, since rubygems has required openssl before the bundler runs it will result in an activated error like this: ``` > bundle exec ruby -ropenssl -e 'p OpenSSL::VERSION' /path/to/2.4.1/lib/ruby/gems/2.4.0/gems/bundler-1.15.4/lib/bundler/runtime.rb:317:in `check_for_activated_spec!': You have already activated openssl 2.0.5, but your Gemfile requires openssl 2.0.4. Prepending `bundle exec` to your command may solve this. (Gem::LoadError) ``` This problem can be avoided by bundling it as a vendoring library under bundler's repository if it is a default gem implemented with pure ruby. Https://github.com/bundler/bundler/blob/master/lib/bundler/vendor/fileutils… In the case of bundler, by separating the namespace as `Bundler::FileUtils`, even the version specified by the user is made available without conflict at the time of activate. However, this method can not be used with C extension library. Since we want to use json/psych from the bundler team with rubygems/bundler to serialize data, we need about whether we can implement a way to avoid some kind of C extension on Ruby itself. I discussed with @indirect who is maintainer of RubyGems/Bundler. We can resolve this problem like following feature of ruby. ``` require_for_bundler 'json', '2.0.2' ``` When we declared above `require_for_bundler`, We put a json-2.0.2 to placed in a namespace like `Bundler::JSON`. There were similar issues in the past as well. https://bugs.ruby-lang.org/issues/10320 I think that the way of writing ```require 'json', version: '2.0.2', into: :Bundler``` which extended the method like this issue seems like that. Also, in this use case, it seems to be enough to use ```require 'json', version: :default, into: :Bundler``` which forces the use of default gem. Matz, How do you think about this feature? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116615] [Ruby master Bug#20243] M:N threading VM_ASSERT failure in rb_current_execution_context with clang 17 (on Linux)
by kjtsanaktsidis (KJ Tsanaktsidis) 24 Aug '26

24 Aug '26

Issue #20243 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20243: M:N threading VM_ASSERT failure in rb_current_execution_context with clang 17 (on Linux) https://bugs.ruby-lang.org/issues/20243 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When building with Clang 17 and `-DVM_CHECK_MODE=1` (with the following configure) ``` optflags="-ggdb3 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O3" cflags="-DVM_CHECK_MODE=1" CC=clang ../configure --prefix=/home/kj/ruby/installed --enable-yjit=dev --disable-install-doc ``` And then running the following script with the built `./miniruby` (which is actually from `bootstraptest/test_ractor.rb`): ```ruby counts = [] counts << Ractor.count ractors = (1..3).map { Ractor.new { Ractor.receive } } counts << Ractor.count ractors[0].send('End 0').take sleep 0.1 until ractors[0].inspect =~ /terminated/ counts << Ractor.count ractors[1].send('End 1').take sleep 0.1 until ractors[1].inspect =~ /terminated/ counts << Ractor.count ractors[2].send('End 2').take sleep 0.1 until ractors[2].inspect =~ /terminated/ counts << Ractor.count counts.inspect ``` I get the following crash: ``` Assertion Failed: ../vm_core.h:1957:rb_current_execution_context:ec == rb_current_ec_noinline() ruby 3.4.0dev (2024-02-07T07:52:06Z ktsanaktsidis/igno.. 5cc6d944c2) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0003 s:0010 e:000009 METHOD <internal:ractor>:431 c:0002 p:0004 s:0006 e:000005 BLOCK ractor_crash.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ractor_crash.rb:3:in `block (2 levels) in <main>' <internal:ractor>:431:in `receive' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/kj/ruby/build/miniruby(rb_print_backtrace+0x14) [0x55faa97a4ebd] ../vm_dump.c:820 /home/kj/ruby/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1151 /home/kj/ruby/build/miniruby(rb_assert_failure+0x81) [0x55faa94d2719] ../error.c:1131 ./miniruby(thread_sched_wait_running_turn+0x2e9) [0x55faa9726f59] /home/kj/ruby/build/miniruby(rb_ractor_sched_sleep+0x10b) [0x55faa972687b] ../thread_pthread.c:1348 /home/kj/ruby/build/miniruby(ractor_check_ints+0x0) [0x55faa968b328] ../ractor.c:683 /home/kj/ruby/build/miniruby(ractor_sleep_with_cleanup) ../ractor.c:684 /home/kj/ruby/build/miniruby(ractor_sleep+0x15) [0x55faa968adf4] ../ractor.c:701 /home/kj/ruby/build/miniruby(ractor_wait_receive) ../ractor.c:748 /home/kj/ruby/build/miniruby(ractor_receive+0x1f) [0x55faa968768e] ../ractor.c:762 /home/kj/ruby/build/miniruby(builtin_inline_class_431) ../ractor.rb:432 /home/kj/ruby/build/miniruby(builtin_invoker0+0x6) [0x55faa978fc66] ../vm_insnhelper.c:6746 /home/kj/ruby/build/miniruby(invoke_bf+0x39) [0x55faa979816e] ../vm_insnhelper.c:6886 /home/kj/ruby/build/miniruby(vm_invoke_builtin_delegate) ../vm_insnhelper.c:6909 /home/kj/ruby/build/miniruby(rb_vm_check_ints+0x0) [0x55faa9771fac] ../insns.def:1533 /home/kj/ruby/build/miniruby(vm_pop_frame) ../vm_insnhelper.c:419 /home/kj/ruby/build/miniruby(vm_exec_core) ../insns.def:1537 /home/kj/ruby/build/miniruby(vm_exec_loop+0x0) [0x55faa9767f02] ../vm.c:2489 /home/kj/ruby/build/miniruby(rb_vm_exec) ../vm.c:2492 /home/kj/ruby/build/miniruby(invoke_block+0x6f) [0x55faa9781a58] ../vm.c:1512 /home/kj/ruby/build/miniruby(invoke_iseq_block_from_c) ../vm.c:1582 /home/kj/ruby/build/miniruby(invoke_block_from_c_proc) ../vm.c:1680 /home/kj/ruby/build/miniruby(vm_invoke_proc) ../vm.c:1710 /home/kj/ruby/build/miniruby(rb_vm_invoke_proc_with_self+0x5a) [0x55faa9781eaa] ../vm.c:1745 /home/kj/ruby/build/miniruby(thread_do_start_proc+0x199) [0x55faa9739e19] ../thread.c:574 /home/kj/ruby/build/miniruby(thread_do_start+0x6c) [0x55faa973933f] ../thread.c:618 /home/kj/ruby/build/miniruby(thread_start_func_2) ../thread.c:668 /home/kj/ruby/build/miniruby(rb_native_mutex_lock+0x0) [0x55faa973a141] ../thread_pthread.c:2234 /home/kj/ruby/build/miniruby(thread_sched_lock_) ../thread_pthread.c:387 /home/kj/ruby/build/miniruby(call_thread_start_func_2) ../thread_pthread_mn.c:436 /home/kj/ruby/build/miniruby(co_start) ../thread_pthread_mn.c:434 ``` The failing assertion is this one in vm_core.h: https://github.com/ruby/ruby/blob/42c36269403baac67b0d5dc1d6d6e31168cf6a1f/…. It actually has a very helpful comment. ``` /* On the shared objects, `__tls_get_addr()` is used to access the TLS * and the address of the `ruby_current_ec` can be stored on a function * frame. However, this address can be mis-used after native thread * migration of a coroutine. * 1) Get `ptr =&ruby_current_ec` op NT1 and store it on the frame. * 2) Context switch and resume it on the NT2. * 3) `ptr` is used on NT2 but it accesses to the TLS on NT1. * This assertion checks such misusage. * * To avoid accidents, `GET_EC()` should be called once on the frame. * Note that inlining can produce the problem. */ VM_ASSERT(ec == rb_current_ec_noinline()); ``` What seems to be happening is exactly that. This is a disassembly of the relevant bits of `thread_sched_wait_running_turn`: ``` ........ # This is the only bits of the entire function which access the TLS base register %fs. # It seems to have spilled the value of ruby_current_ec into %r13. 0x000055603d2e1cf8 <+136>: mov $0xffffffffffffff90,%rax 0x000055603d2e1cff <+143>: mov %fs:0x0,%r12 0x000055603d2e1d08 <+152>: add %rax,%r12 0x000055603d2e1d0b <+155>: mov %fs:(%rax),%r13 ........ # There's a call to coroutine_transfer, so after this point we're returned to on a # different thread 0x000055603d2e1e90 <+544>: call 0x55603d7fce84 <coroutine_transfer> # But nothing ever loads the address of ruby_current_ec from %fs again (i didn't trace # exactly the data flow from %r13 at 0x000055603d2e1d0b to here, but i assume it spilled # somewhere and now got loaded back into %r15 here). In any case, that means %r15 here # contains the value of ruby_current_ec from the _old_ thread, not the current one. 0x000055603d2e1e95 <+549>: mov %rbx,0x28(%r14) 0x000055603d2e1e99 <+553>: mov (%r12),%r15 0x000055603d2e1e9d <+557>: call 0x55603d33a010 <rb_current_ec_noinline> 0x000055603d2e1ea2 <+562>: cmp %rax,%r15 => 0x000055603d2e1ea5 <+565>: jne 0x55603d2e1f3a <thread_sched_wait_running_turn+714> ........ # assertion failure code path. 0x000055603d2e1f3a <+714>: lea 0x542c0c(%rip),%rdi # 0x55603d824b4d 0x000055603d2e1f41 <+721>: lea 0x542c12(%rip),%rdx # 0x55603d824b5a 0x000055603d2e1f48 <+728>: lea 0x542c28(%rip),%rcx # 0x55603d824b77 0x000055603d2e1f4f <+735>: mov $0x7a5,%esi 0x000055603d2e1f54 <+740>: call 0x55603d08d698 <rb_assert_failure> ``` if we look at the register values from `0x000055603d2e1ea2`: ``` (rr) print/x $rax $2 = 0x55603e159ad0 (rr) print/x $r15 $3 = 0x0 ``` So the value from `%rax` which came from `ruby_current_ec_noinline` is correctly the value of `ruby_current_ec` for this thread, and `%r15` contains a stale value from a previous thread. - Now, what can we _do_ about this, is a different question :/ There's a really good stackoverflow answer about it here: https://stackoverflow.com/questions/75592038/how-to-disable-clang-expressio…, but to summarise * longstanding GCC and Clang bugs for this exist and have been marked as WONTFIX (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461, https://github.com/llvm/llvm-project/issues/19551) * It's even worse than this EC problem - things like `errno` also might be incorrectly persisted across coroutine switches (so e.g. an inlined C library function could in theory set `errno` in another thread, for example) * C++ actually has coroutines now, so this _must_ work for those. Clang at least has fixed some TLS problems in their C++ coroutine implementation (https://github.com/llvm/llvm-project/issues/47179) Other than reimplementing all of our coroutine stuff on top of C++ coroutines, I'm not sure what else we can do. AFAICT there's no way to tell the compiler that we clobbered the `%fs` register because that's just not a thing in its model (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631, but i assume clang is similar). Thoughts? For now I think my workaround is to disable M:N at build time when building with ASAN (or turn optimizations down). At least this isn't a problem with `Fiber` because we never move them across threads (probably for this reason in part). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126480] [Ruby Bug#22259] Arrays sharding a buffer segfault when concatenating with each other
by chucke (Tiago Cardoso) 24 Aug '26

24 Aug '26

Issue #22259 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22259: Arrays sharding a buffer segfault when concatenating with each other https://bugs.ruby-lang.org/issues/22259 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A succession of crashes was observed on a particular workload from our app, involving recursive set operations, after upgrading it to ruby 4.0.6 . LLM was used to build a reproduction (shared in the description of the PR linked below), after which we used it as a harness to get to the actual culprit and fix it. The crash is due to a particular behaviour of how (btw, TIL, so correct my explanation if necessary) ruby arrays share internal buffers, for optimal memory usage. `Array#dup` creates a separate array object, but may share (under certain conditions, i.e. does not embed) the internal C buffer, where objects are stored, with it. Certain modification operations, like `Array#dup`, don't forcefully "copy on write", and instead bump/dec an index on the shared buffer, as so to determine the slice of the original shared buffer it points to. The issue happens with how other operations work, such as `Array#concat`, which is, internally, under certain conditions, copying the full shared buffer to the destination array buffer, without regards of which slice it is about. This is easily demonstrable by the first reproduction in the PR linked below, where the last `concat` operation adds a "phantom" element to the destination array. that element is, at that point, gibberish, malloc-uninitialized data, which causes the VM to crash, depending on what it does with the address found there. This bug has been there for a while, and can be reproduced (with different faulty outcomes) since ruby 3.3 at least (didn't try further back). PR with fix here: https://github.com/ruby/ruby/pull/18472 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126279] [Ruby Feature#22231] Add `IO::Buffer#index`
by himura467 (Akito Shitara) 24 Aug '26

24 Aug '26

Issue #22231 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22231: Add `IO::Buffer#index` https://bugs.ruby-lang.org/issues/22231 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ## Use case `IO::Buffer` has no search primitive: no `#index`, no delimiter scan, no substring search. This matters for servers that hand request data to the application as zero-copy `IO::Buffer` views over their own socket read buffer. The zero-copy path ends at the first delimiter scan, such as splitting a query string on `&`, finding a multipart boundary, or scanning a header value, which is where request processing usually begins. The same applies to any protocol parser built on `IO::Buffer`: line framing, chunked transfer encoding, netstrings, length-prefixed records. All of them must find a delimiter before they can decide what to slice. Today there are two ways to do it, and both give up what the buffer was for: ```ruby buffer.get_string.index("&") # copies the whole region to find one offset i = 0 # no copy, but a method call per byte i += 1 while i < buffer.size && buffer.get_value(:U8, i) != 0x26 ``` Searching a 64 KiB body by copying it out is 3.7x slower than searching it in place, and allocates 66 KB per call. The byte loop allocates nothing but is roughly 1570x slower. ## Specification ```ruby buffer.index(object, offset = 0, length = size - offset) # => Integer or nil ``` `object` may be an `Integer` byte value (`0..255`), a `String`, or another `IO::Buffer`. ```ruby buffer = IO::Buffer.for("Hello World") buffer.index("World") # => 6 buffer.index("o".ord) # => 4 buffer.index(IO::Buffer.for("World")) # => 6 buffer.index("!") # => nil buffer.index("o", 5) # => 7 (absolute, not relative to offset) buffer.slice(6, 5).index("o") # => 1 (relative to the slice) ``` - Searching is byte-oriented; a `String`'s encoding is ignored. - An empty `object` matches at `offset`, as with `String#index`. - An `object` longer than the range returns `nil`. - An out-of-range `offset` or `length` raises `ArgumentError` (see below). Single-byte values use `memchr`. Longer values reuse `rb_memsearch`, the portable substring search that already backs `String#index`. ## Open questions ### Out-of-range `offset`/`length` raises, where `String#index` returns `nil`. All ten existing `(offset, length)` methods in `io_buffer.c` route through `io_buffer_validate_range` and raise, and the class never clamps. `String#index` also has no `length` parameter, so matching it does not settle what `length` should do; the Ruby-wide convention there is to clamp, as in `"hello".byteslice(0, 1000)`, which is what `IO::Buffer` declines to do elsewhere. I chose consistency within the class, and am happy to switch if the `String` reading is preferred. ### An `Integer` outside `0..255` raises, where `#clear` masks it. `buffer.clear(256)` fills with `0`, and `String#setbyte` masks too. Masking a value being searched for seems worse than masking one being written, since `index(256)` would quietly search for `\x00` and could return a match. ## Follow-ups `#rindex` for a reverse scan, and an `#each_until(delimiter)` framing iterator yielding successive delimited slices, in the same spirit as the vectorizable `#and!` / `#or!` / `#bit_count` family. Both build on `#index`, so this ticket is scoped to it. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126481] [Ruby Bug#22260] Ruby::Box: SIGSEGV when calling a method inside an isolated Proc defined at class/module body (RUBY_BOX=1)
by zonuexe (Kenta USAMI) 24 Aug '26

24 Aug '26

Issue #22260 has been reported by zonuexe (Kenta USAMI). ---------------------------------------- Bug #22260: Ruby::Box: SIGSEGV when calling a method inside an isolated Proc defined at class/module body (RUBY_BOX=1) https://bugs.ruby-lang.org/issues/22260 * Author: zonuexe (Kenta USAMI) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-24T10:31:23Z master 042e2bfd39) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary Under `RUBY_BOX=1`, any method call inside a Proc isolated by `Ractor.make_shareable` (or `Proc#isolate`) and defined at a class/module body crashes the VM: ```console $ RUBY_BOX=1 ruby -e 'module M; L = Ractor.make_shareable(->(*a){ Rational(*a) }); end; p M::L.call(3, 4)' -e:1: [BUG] Segmentation fault at 0x0000000000000000 $ ruby -e 'module M; L = Ractor.make_shareable(->(*a){ Rational(*a) }); end; p M::L.call(3, 4)' (3/4) ``` The Proc body does not matter (`a.to_s`, `1.zero?`, `String.name` all crash). A Proc defined inside a method body works. No user sub-boxes are involved. Backtrace: `rb_vm_search_method_slowpath` → `callable_method_entry_or_negative` → `search_method0`, faulting in `RCLASS_EXT_TABLE_LOOKUP_INTERNAL` with `box == NULL` (`box->box_object` sits at offset 0 of `rb_box_t`, hence address 0x0). ## Root cause A TOP/CLASS frame's env stores its box pointer in the SPECVAL slot; that is what `VM_ENV_BOX()` reads and `rb_current_box()` returns via `current_box_on_cfp()`. `env_copy()` (vm.c, called from `proc_isolate_env()`) rebuilds a local env with ```c else { ep[VM_ENV_DATA_INDEX_SPECVAL] = VM_BLOCK_HANDLER_NONE; } ``` so the copy keeps its frame type but loses its box. The first method lookup inside the isolated Proc then dereferences the NULL box. ## Proposed patch Copy the SPECVAL slot through for TOP/CLASS envs (patch attached, with a regression test in test/ruby/test_box.rb): ```c else if (VM_ENV_BOXED_P(src_ep)) { ep[VM_ENV_DATA_INDEX_SPECVAL] = src_ep[VM_ENV_DATA_INDEX_SPECVAL]; } ``` On master (042e2bfd39) the new test segfaults before the patch and passes after it; test_box.rb, test_proc.rb and test_ractor.rb stay green (288 tests, 0 failures). ## Context Hit by the [Rigor](https://github.com/rigortype/rigor) static analyzer, which calls `Ractor.make_shareable`d module-scope lambdas from worker Ractors. With the patch, analyzing the whole Redmine codebase under `RUBY_BOX=1` completes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115143] [Ruby master Bug#19970] Eval leaks callcache and callinfo objects on arm32 (linux)
by larsin (Lars Ingjer) 24 Aug '26

24 Aug '26

Issue #19970 has been reported by larsin (Lars Ingjer). ---------------------------------------- Bug #19970: Eval leaks callcache and callinfo objects on arm32 (linux) https://bugs.ruby-lang.org/issues/19970 * Author: larsin (Lars Ingjer) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [armv7l-linux-eabihf] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following script demonstrates a memory leak on arm 32 (linux): ``` ruby def gcdiff(n) GC.start if @last_gc_stat puts "GC.stat #{n} diff old_objects: #{GC.stat(:old_objects) - @last_gc_stat}" end @last_gc_stat = GC.stat(:old_objects) end def foo end 10.times do |i| 10_000.times do eval 'foo' end gcdiff(i) puts "Number of live objects: #{GC.stat(:heap_live_slots)}" puts "Memory usage: #{`ps -o rss= -p #{$$}`}" puts end ``` Output: ``` Number of live objects: 41303 Memory usage: 11900 GC.stat 1 diff old_objects: 20037 Number of live objects: 61317 Memory usage: 13604 GC.stat 2 diff old_objects: 20001 Number of live objects: 81317 Memory usage: 14880 GC.stat 3 diff old_objects: 20000 Number of live objects: 101317 Memory usage: 16596 GC.stat 4 diff old_objects: 20000 Number of live objects: 121317 Memory usage: 17248 GC.stat 5 diff old_objects: 20000 Number of live objects: 141317 Memory usage: 18760 GC.stat 6 diff old_objects: 20000 Number of live objects: 161317 Memory usage: 19540 GC.stat 7 diff old_objects: 20000 Number of live objects: 181317 Memory usage: 21752 GC.stat 8 diff old_objects: 20000 Number of live objects: 201317 Memory usage: 21828 GC.stat 9 diff old_objects: 20000 Number of live objects: 221317 Memory usage: 24896 ``` ObjectSpace.count_imemo_objects shows that imemo_callcache and imemo_callinfo are leaking. The issue does not occur on arm64 mac or x86_64 linux with the same ruby version. The issue has also been reproduced with the latest 3.2.2 snapshot (2023-09-30). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126477] [Ruby Bug#22258] Update bundled json to >= 2.19.2 on ruby_4_0 (CVE-2026-33210)
by securepii-dev (Russell Penney) 24 Aug '26

24 Aug '26

Issue #22258 has been reported by securepii-dev (Russell Penney). ---------------------------------------- Bug #22258: Update bundled json to >= 2.19.2 on ruby_4_0 (CVE-2026-33210) https://bugs.ruby-lang.org/issues/22258 * Author: securepii-dev (Russell Penney) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x64-mingw-ucrt] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The ruby_4_0 branch bundles json 2.18.0 (ext/json/lib/json/version.rb), which is affected by CVE-2026-33210 / GHSA-3m6g-2423-7cp3 (format string injection when parsing with allow_duplicate_key: false, fixed in json 2.19.2 — there is no patched 2.18.x release). All 4.0.0–4.0.6 releases and the official ruby:4.0 Docker images therefore ship a vulnerable json and are flagged by container scanners (AWS Inspector, Trivy, ECR scanning), which is problematic for compliance-scoped environments (e.g. PCI DSS). master has already synced json 3.0.0.rc1. Please sync json >= 2.19.2 to ruby_4_0 so it's included in 4.0.7. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111740] [Ruby master Bug#19325] Windows support lacking.
by dsisnero (Dominic Sisneros) 23 Aug '26

23 Aug '26

Issue #19325 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Bug #19325: Windows support lacking. https://bugs.ruby-lang.org/issues/19325 * Author: dsisnero (Dominic Sisneros) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2. -- https://bugs.ruby-lang.org/

10 12

[ruby-core:118182] [Ruby master Bug#20526] File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows
by kou (Kouhei Sutou) 23 Aug '26

23 Aug '26

Issue #20526 has been reported by kou (Kouhei Sutou). ---------------------------------------- Bug #20526: File.open(encoding: "bom|utf-8") converts "\r\n" to "\n" on Windows https://bugs.ruby-lang.org/issues/20526 * Author: kou (Kouhei Sutou) * Status: Open * Target version: 3.2 * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm not sure whether this is an intentional behavior but it seems that `encoding: "utf-8"` doesn't change newline conversion but `encoding: "bom|utf-8"` changes newline conversion: ```ruby File.write("a.txt", "a\r\n") File.read("a.txt").bytes # => [97, 13, 10] File.open("a.txt", encoding: "utf-8") {|f| f.read.bytes} # => [97, 10, 10] File.open("a.txt", encoding: "bom|utf-8") {|f| f.read.bytes} # => [97, 10] XXX: \r\n -> \n File.open("a.txt", encoding: "bom|utf-8", universal_newline: false) {|f| f.read.bytes} # => [97, 13, 10] ``` Note that the `XXX: ` line the above codes. Is this an intentional behavior? -- https://bugs.ruby-lang.org/

3 4