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

[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) 27 Aug '26

27 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/

1 2

[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

[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: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: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

[ruby-core:124029] [Ruby Bug#21765] stop using the C runtime _read() on Windows
by YO4 (Yoshinao Muramatsu) 23 Aug '26

23 Aug '26

Issue #21765 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21765: stop using the C runtime _read() on Windows https://bugs.ruby-lang.org/issues/21765 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When creating an IO instance in Windows, the default data mode is text mode. In reality, the IO encoding conversion mechanism is not used when encoding conversion is not performed. Instead, the CRLF conversion provided by the C runtime's `_read()` is used. This is explicitly for speed. https://bugs.ruby-lang.org/issues/6401#note-4 As a trade-off, `SET_BINARY_MODE(fptr)` and `SET_BINARY_MODE_WITH_SEEK_CUR(fptr)` are used in various places within io.c, altering the state of the file descriptor. This made the flow of operations difficult to understand and changes hard to implement, especially for developers on other platforms. Additionally, the issues I recently reported were discovered while verifying the impact of modifying the CRLF conversion to utilize the encoding conversion mechanism. #21691 On Windows some of binary read functions of IO are not functional #21687 IO＃pos goes wrong after EOF character(ctrl-z) met #21634 Combining read(1) with eof? causes dropout of results unexpectedly on Windows. These issues arise because data read into the rbuf does not match the stream due to newline conversion, or because the buffer end and file position do not align when CTRLZ is detected. As a fix for Bug #21687, I created PR #15216. However, this relies on the internal behavior of the C runtime's `_read()` function, and it seems there is no way to avoid this dependency. **I propose removing the use of C runtime _read().** Reason for Proposal - The mismatch between rbuf and stream contents complicates io_unread() and makes maintenance difficult. - Changing the O_BINARY/O_TEXT state of the file descriptor in various places hinders understanding of the behavior and makes modifications difficult. Two methods to remove C runtime _read() while maintaining current behavior 1. Interpret CRLF and CTRLZ when reading rbuf within io.c. 1. Interpret CRLF and CTRLZ within the encoding conversion framework. My initial idea was to implement the second, using encoding conversion. However, this internally changes the read operation from rbuf to cbuf, resulting in a change to the behavior of ungetc. The proposal in Bug #21682 attempted to generalize this change to minimize its impact. https://bugs.ruby-lang.org/issues/21682 **This issue proposes the first method, crlf conversion during rbuf read.** Problems caused by inconsistencies between the rbuf and stream contents are avoided, and io_unread() becomes the same as on other platforms. Compared to implementing it as an encoding conversion, the advantage is that there is no change in behavior. On the other hand, since each read method in io.c requires individual handling, using encoding conversion results in more localized changes. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115466] [Ruby master Bug#20020] Segfault running regexp match?
by andrea.salicetti＠gmail.com (Andrea Salicetti) 23 Aug '26

23 Aug '26

Issue #20020 has been reported by andrea.salicetti(a)gmail.com (Andrea Salicetti). ---------------------------------------- Bug #20020: Segfault running regexp match? https://bugs.ruby-lang.org/issues/20020 * Author: andrea.salicetti(a)gmail.com (Andrea Salicetti) * Status: Open * Priority: Normal * ruby -v: 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- **Ruby version** : ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] From `irb`, trying to call `match?` on this regular expression causes a segmentation falut: ```ruby irb(main):001:0> /^((a|c)|\s?){1,3}$/.match?('abc') => false irb(main):002:0> /^((a|c)|\s?){1,3}$/.match?('abc') (irb):2: [BUG] Segmentation fault at 0x000000061ba998e8 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0037 p:---- s:0207 e:000206 CFUNC :match? c:0036 p:0006 s:0202 e:000201 EVAL (irb):2 [FINISH] c:0035 p:---- s:0199 e:000198 CFUNC :eval c:0034 p:0020 s:0191 e:000190 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/workspace.rb:119 c:0033 p:0153 s:0183 e:000181 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/context.rb:502 c:0032 p:0119 s:0170 e:000169 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:588 c:0031 p:0024 s:0164 e:000163 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:777 c:0030 p:0007 s:0158 e:000157 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:567 c:0029 p:0126 s:0153 e:000152 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:267 [FINISH] c:0028 p:---- s:0149 e:000148 CFUNC :loop c:0027 p:0005 s:0145 e:000144 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:249 [FINISH] c:0026 p:---- s:0142 e:000141 CFUNC :catch c:0025 p:0010 s:0137 e:000136 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:248 c:0024 p:0050 s:0132 E:000dd8 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:566 c:0023 p:0003 s:0127 e:000126 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:500 [FINISH] c:0022 p:---- s:0124 e:000123 CFUNC :catch c:0021 p:0050 s:0119 E:000d50 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:499 c:0020 p:0069 s:0113 e:000112 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:421 c:0019 p:0012 s:0107 e:000106 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11 [FINISH] c:0018 p:---- s:0104 e:000103 CFUNC :load c:0017 p:0078 s:0099 e:000098 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/irb:25 [FINISH] c:0016 p:---- s:0094 e:000093 CFUNC :load c:0015 p:0064 s:0089 e:000088 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:58 c:0014 p:0050 s:0083 e:000082 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:23 c:0013 p:0034 s:0078 e:000077 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:492 c:0012 p:0054 s:0073 e:000072 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:28 c:0011 p:0040 s:0065 e:000064 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127 c:0010 p:0213 s:0058 e:000057 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:527 c:0009 p:0008 s:0045 e:000044 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:34 c:0008 p:0044 s:0040 e:000039 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:584 c:0007 p:0022 s:0033 e:000032 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:28 c:0006 p:0042 s:0028 e:000027 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:37 c:0005 p:0007 s:0022 e:000021 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/friendly_errors.rb:117 c:0004 p:0108 s:0017 E:0019b8 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:29 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0081 s:0008 E:000220 EVAL /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/bundle:25 [FINISH] c:0001 p:0000 s:0003 E:001980 DUMMY [FINISH] ``` Sometimes this happens the very first time I try to execute the command, some other times I have to try a couple of times to see that Segmentation Fault (but usually within the first 5 attempts). ---Files-------------------------------- ruby-2023-11-23-175410.ips (20.2 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124335] [Ruby Bug#21798] `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled
by unasuke (Yusuke Nakamura) 23 Aug '26

23 Aug '26

Issue #21798 has been reported by unasuke (Yusuke Nakamura). ---------------------------------------- Bug #21798: `bundle install` command fails if touches `$LOAD_PATH` on `Ruby::Box` enabled https://bugs.ruby-lang.org/issues/21798 * Author: unasuke (Yusuke Nakamura) * Status: Open * ruby -v: 4.0.0-preview3 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## How to reproduce ```dockerfile FROM ruby:4.0.0-preview3-trixie WORKDIR /ruby_box_test RUN bundle gem foo --test=minitest WORKDIR /ruby_box_test/foo RUN head -n 10 foo.gemspec # PASS RUN bundle install # PASS RUN RUBY_BOX=1 bundle install RUN sed --in-place \ --expression='2i lib=File.expand_path("../lib", __FILE__)\n$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)' \ foo.gemspec RUN sed --in-place \ --expression='s/require_relative "lib\/foo\/version"/require "foo\/version"/' \ foo.gemspec RUN head -n 10 foo.gemspec # PASS RUN bundle install # FAIL RUN RUBY_BOX=1 bundle install ``` This script fails. ``` /usr/local/bin/ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. [!] There was an error while loading `foo.gemspec`: cannot load such file -- foo/version. Bundler cannot continue. # from /ruby_box_test/foo/foo.gemspec:5 # ------------------------------------------- # > require "foo/version" # # ------------------------------------------- Error: building at STEP "RUN RUBY_BOX=1 bundle install": while running runtime: exit status 14 ``` Head of the gemspec file is this. ```ruby # frozen_string_literal: true lib=File.expand_path("../lib", __FILE__) $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib) require "foo/version" Gem::Specification.new do |spec| # ..snip.. end ``` # misc I found this behavior when `RUBY_BOX=1 bundle exec rake spec` on `https://github.com/itamae-kitchen/itamae`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126083] [Ruby Bug#22195] `IO::Buffer` read after free silently returns empty data instead of raising
by himura467 (Akito Shitara) 22 Aug '26

22 Aug '26

Issue #22195 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22195: `IO::Buffer` read after free silently returns empty data instead of raising https://bugs.ruby-lang.org/issues/22195 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Reading from an `IO::Buffer` after calling `#free` does not raise. It behaves like an empty buffer, and `#valid?` still returns `true`: ```ruby buffer = IO::Buffer.for("Hello World") buffer.free buffer.valid? # => true buffer.get_string # => "" (no error) ``` ## Why this looks like an unintended regression Originally (https://github.com/ruby/ruby/commit/e30920354f, Ruby 3.1–3.3), accessing a freed buffer raised `IO::Buffer::AllocationError` ("The buffer is not allocated!"). https://github.com/ruby/ruby/commit/c5cf4d4e12 made zero-length buffer operations succeed instead of raising, for [Bug #19542] and [Bug #18805]. Since a freed buffer also has `base == NULL, size == 0`, it was caught in the same code path and stopped raising too. Neither ticket mentions freed buffers, so this appears to be an accidental side effect rather than a decision. Note that the rdoc of `#free` still promises that access after free raises. ## Proposal How about marking a buffer as invalidated when it is explicitly freed (`#free` / `rb_io_buffer_free`), so that: * `#valid?` returns `false`. * Any byte access raises `IO::Buffer::InvalidatedError` or `IO::Buffer::AllocationError`. * `#resize` re-allocates and clears the mark, as `#free`'s rdoc promises ("You can resize a freed buffer to re-allocate it"). * The zero-length buffer semantics from https://github.com/ruby/ruby/pull/9532 are preserved: `IO::Buffer.new(0)`, `resize(0)` and zero-length slices remain valid and readable. I'm not sure which exception class is preferable: `IO::Buffer::InvalidatedError` is consistent with how invalidated slices already behave and with `#valid?` returning `false`, while `IO::Buffer::AllocationError` restores the pre-3.4 behavior. -- https://bugs.ruby-lang.org/

2 5