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

[ruby-core:124711] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching
by synacker (Mikhail Milovidov) 12 Sep '26

12 Sep '26

Issue #21869 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21869: Add receive_all Method to Ractor API for Message Batching https://bugs.ruby-lang.org/issues/21869 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** The Ractor API provides an excellent mechanism for inter‑thread communication, but it currently lacks a built‑in message batching technique. I propose adding a receive_all method to enable batch processing of messages, which can significantly improve performance in high‑load scenarios. **Motivation** In distributed queued systems, processing messages one‑by‑one (as with the current receive method) can introduce unnecessary overhead. Batch processing allows: Reduced context‑switching overhead. More efficient I/O operations (e.g., fewer file writes). Better throughput in high‑concurrency environments. **Proposed Solution** Add a receive_all method to the Ractor API that: Returns all available messages in the Ractor’s mailbox at once (as an array). **Demonstration Code** Below is a benchmark comparing individual receive vs. batch receive_all: ``` ruby require 'benchmark' class RactorsTest def initialize(count) @count = count @ractor1 = Ractor.new(count, 'output1.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? message = receive file.write("Ractor 1 received message: #{message}\n") file.flush count -= 1 end end end @ractor2 = Ractor.new(count, 'output2.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? messages = receive_all messages.each do |message| file.write("Ractor 2 received message: #{message}\n") end count -= messages.length file.flush end end end end def run1 @count.times do |i| @ractor1.send("Message #{i + 1}") end @ractor1.join end def run2 @count.times do |i| @ractor2.send("Message #{i + 1}") end @ractor2.join end end records = 1_000_000 test = RactorsTest.new(records) p [:once, Benchmark.realtime { test.run1 }.round(2)] p [:all, Benchmark.realtime { test.run2 }.round(2)] ``` **Benchmark Results** On my system, receive_all shows ~4x improvement over individual receive: **Key Observations:** Ractor1 (using receive): Processes each message individually, resulting in frequent I/O calls. Ractor2 (using receive_all): Processes all queued messages at once, minimizing I/O overhead -- https://bugs.ruby-lang.org/

4 12

[ruby-core:124851] [Ruby Bug#21918] fiber scheduler: fiber interrupt triggers for IOs that haven't been closed
by chucke (Tiago Cardoso) 12 Sep '26

12 Sep '26

Issue #21918 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21918: fiber scheduler: fiber interrupt triggers for IOs that haven't been closed https://bugs.ruby-lang.org/issues/21918 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've been chasing an issue, which I believe is to with the recent introduction of the `fiber_interrupt` hook in ruby 4. As a reproduction I have the following snippet: ```ruby require "socket" require_relative "test/fiber/scheduler" # use the one defined here: https://github.com/ruby/ruby/blob/master/test/fiber/scheduler.rb udp = UDPSocket.new(Socket::AF_INET) tcp = Socket.new(Socket::AF_INET, :STREAM, 0) tcp.connect(Socket.sockaddr_in(80, "nghttp2")) t = Thread.start do Thread.current.abort_on_exception = true scheduler = Scheduler.new Fiber.set_scheduler scheduler 5.times do Fiber.schedule do begin puts "#{Fiber.current.object_id} -> wait udp" udp.to_io.wait_readable(2) rescue IOError => e puts "#{Fiber.current.object_id} -> udp io error: #{e}" end begin puts "#{Fiber.current.object_id} -> closing udp" udp.close puts "#{Fiber.current.object_id} -> closed udp" puts "#{Fiber.current.object_id} -> wait tcp" tcp.to_io.wait_readable(2) puts "#{Fiber.current.object_id} -> done" rescue => e puts "#{Fiber.current.object_id} -> tcp io error: #{e}" else puts "#{Fiber.current.object_id} -> closing tcp" tcp.close end end end end t.join ``` This produces the following output to me: ``` 1472 -> wait udp 1488 -> wait udp 1496 -> wait udp 1504 -> wait udp 1512 -> wait udp 1472 -> closing udp 1488 -> closing udp 1488 -> closed udp 1488 -> wait tcp 1496 -> closing udp 1496 -> closed udp 1496 -> wait tcp 1504 -> closing udp 1504 -> closed udp 1504 -> wait tcp 1512 -> closing udp 1512 -> closed udp 1512 -> wait tcp 1512 -> tcp io error: stream closed in another thread 1504 -> tcp io error: stream closed in another thread 1496 -> tcp io error: stream closed in another thread 1488 -> tcp io error: stream closed in another thread 1472 -> closed udp 1472 -> wait tcp 1472 -> done 1472 -> closing tcp ``` The thing that makes this program very confusing is that the "stream closed in another thread" related to the udp socket is raised while waiting for read readiness on the tcp socket. In such a situation, I'd expect the error to relate to the actual socket being waited on, not something else that fiber does not care about anymore. One thing that could have helped would be to have the reference of which IO object the exception relates to in the exception (aka `IOError#io` would return the socket). Nevertheless, I'd still consider an issue that this triggers in the wrong "fiber.yield" moment. Therefore, I think there are two possible outcomes here: 1. all fibers stop on `udp.close` until it is in fact closed (and then IOError is raised before the "closed udp" message can be printed) 2. exceptions related to IOs not actively being monitored by the current fiber are ignored. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125416] [Ruby Feature#22056] Add zero-copy String constructor backed by an arbitrary Ruby object
by himura467 (Akito Shitara) 11 Sep '26

11 Sep '26

Issue #22056 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22056: Add zero-copy String constructor backed by an arbitrary Ruby object https://bugs.ruby-lang.org/issues/22056 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ### Description Ruby has rich built-in functionality for working with byte sequences through `String`. Objects that manage their own byte buffers naturally want to expose their data through this interface. The straightforward approach is `rb_str_new()`, which copies the bytes: ``` c VALUE str = rb_str_new(str, len); ``` For large or frequently accessed buffers this copy is wasteful in both time and memory. One approach is to create a String that directly references the existing memory, with the GC keeping the owner alive for as long as the String is reachable. This avoids both the copy and the need for manual lifetime management. ### Existing APIs and their limitations | API | Memory behavior | | ---- | ---- | | `rb_str_new` / `rb_str_new_cstr` | Copies bytes; String owns the allocation | | `rb_str_new_shared` / `rb_str_new_frozen` | References another String's buffer; parent must be a String | | `rb_str_new_static` | References static (compile-time) storage; no lifetime management | `rb_str_new_static` avoids copying but is only safe for storage that lives forever. When memory is owned by a Ruby object, it is freed when that object is collected, and `rb_str_new_static` offers no way to express that dependency. The common workaround is to pin the owner via an instance variable: ``` c VALUE str = rb_str_new_static(str, len); rb_ivar_set(str, id_owner, owner); ``` This relies on undocumented GC behavior, incurs ivar table allocation overhead, and leaves lifetime management entirely to the caller. ### Proposal Add zero-copy String constructors that accept an explicit parent object. The proposed names are tentative and open for discussion (see below): ``` c VALUE rb_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_usascii_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_utf8_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_enc_str_new_external(const char *ptr, long len, rb_encoding *enc, VALUE parent); ``` `parent` can be any live Ruby object. The GC guarantees it is not collected before the returned String is. `ptr` must point into memory whose lifetime is tied to `parent`; no copy is made. ### Use cases *IO::Buffer#get_string* `IO::Buffer.for(string)` wraps a String's bytes in a READONLY EXTERNAL buffer. `IO::Buffer#get_string` now copies those bytes into a new String. With this API, the returned String can reference the source String directly: ``` c return rb_enc_str_new_external((const char *)base + offset, length, encoding, buffer->source); ``` The returned String holds a direct GC reference to the source String, so it remains valid even after the buffer is freed. *GLib::Bytes#to_s (ruby-gnome)* `GLib::Bytes` is an immutable, reference-counted byte buffer from GLib. The current [implementation](https://github.com/ruby-gnome/ruby-gnome/blob/1dad74d1a86f9… uses the ivar workaround: ``` c VALUE str = rb_str_new_static(data, size); rb_iv_set(str, "@bytes", self); ``` With the proposed API this becomes: ``` c return rb_str_new_external(data, size, self); ``` ### Open questions *Naming* The name `rb_str_new_external` is one option. Other candidates: * `rb_str_new_owned_by` / `rb_enc_str_new_owned_by` * `rb_str_new_pinned` / `rb_enc_str_new_pinned` * `rb_str_new_with_parent` / `rb_enc_str_new_with_parent` *Memory retention* When a String referencing a small slice of a large buffer remains reachable, the entire backing object is kept alive. This is the same concern that led Java to remove the shared-backing optimization from `String.substring()` in Java 7. The risk was also raised in the context of Ruby's own lazy substring proposal (#19315, https://bugs.ruby-lang.org/issues/19315#note-7) > I heard that Java stopped the shared substring technique 10 years ago (https://www.infoq.com/news/2013/12/Oracle-Tunes-Java-String/) because of the potential for memory leaks > > I don't disagree this proposal, but it would be nice if we could evaluate the effectiveness of this optimization. Whether the same concern applies to this proposal, and whether the API should offer a way to force an independent copy, is worth discussing. ### Proof of concept A prototype implementation is at: https://github.com/ruby/ruby/pull/16834 The implementation introduces a new flag on non-embedded strings and stores the parent reference in `RString.as.heap.aux.parent`. The GC mark phase pins embedded parent strings to prevent compaction from invalidating the raw pointer stored in the zero-copy child. -- https://bugs.ruby-lang.org/

7 28

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 10 Sep '26

10 Sep '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:122943] [Ruby Bug#21537] rb_ractor_sched_barrier_start() hangs on Windows
by rhenium (Kazuki Yamaguchi) 09 Sep '26

09 Sep '26

Issue #21537 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #21537: rb_ractor_sched_barrier_start() hangs on Windows https://bugs.ruby-lang.org/issues/21537 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-09T11:32:53Z master 2a6345e957) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script hangs at `GC.start` indefinitely. Pressing Ctrl+C on the terminal interrupts the `sleep` and it appears to resume and prints "in_ractor". ```ruby Ractor.new { sleep 1 GC.start puts "in_ractor" } sleep ``` I also reproduced this with Ruby 3.0.7 from RubyInstaller2. Here is the stack trace with master: ``` 0:006> ~*k 0 Id: 1e88.36c4 Suspend: 1 Teb: 000000c6`92478000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`929fef18 00007ffa`9e4edf43 ntdll!NtWaitForMultipleObjects+0x14 01 000000c6`929fef20 00007ffa`9e4ede11 KERNELBASE!WaitForMultipleObjectsEx+0x123 02 000000c6`929ff210 00007ff6`756b8164 KERNELBASE!WaitForMultipleObjects+0x11 03 000000c6`929ff250 00007ff6`756b13af miniruby!w32_wait_events+0x108 [C:\w\ruby\thread_win32.c @ 239] 04 000000c6`929ff2d0 00007ff6`756b62a2 miniruby!native_sleep+0xc3 [C:\w\ruby\thread_win32.c @ 360] 05 000000c6`929ff310 00007ff6`75646353 miniruby!sleep_forever+0x82 [C:\w\ruby\thread.c @ 1374] 06 000000c6`929ff350 00007ff6`756e5f4b miniruby!rb_f_sleep+0x53 [C:\w\ruby\process.c @ 4975] 07 000000c6`929ff380 00007ff6`756e5df9 miniruby!vm_call_cfunc_with_frame_+0x14b [C:\w\ruby\vm_insnhelper.c @ 3850] 08 000000c6`929ff460 00007ff6`756e5dbb miniruby!vm_call_cfunc_with_frame+0x29 [C:\w\ruby\vm_insnhelper.c @ 3895] 09 000000c6`929ff4a0 00007ff6`756e5ab7 miniruby!vm_call_cfunc_other+0xc7 [C:\w\ruby\vm_insnhelper.c @ 3922] 0a 000000c6`929ff4e0 00007ff6`756e8363 miniruby!vm_call_cfunc+0x10b [C:\w\ruby\vm_insnhelper.c @ 4003] 0b 000000c6`929ff510 00007ff6`756e7cfe miniruby!vm_call_method_each_type+0x637 [C:\w\ruby\vm_insnhelper.c @ 4827] 0c 000000c6`929ff610 00007ff6`756f39b4 miniruby!vm_call_method+0x152 [C:\w\ruby\vm_insnhelper.c @ 4991] 0d 000000c6`929ff680 00007ff6`756ee003 miniruby!vm_sendish+0x1f4 [C:\w\ruby\vm_insnhelper.c @ 6065] 0e 000000c6`929ff700 00007ff6`756e0f27 miniruby!vm_exec_core+0x25cb [C:\w\ruby\insns.def @ 900] 0f (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 10 000000c6`929ff860 00007ff6`755b896f miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 11 000000c6`929ff9d0 00007ff6`755baf47 miniruby!rb_ec_exec_node+0x10f [C:\w\ruby\eval.c @ 284] 12 000000c6`929ffb50 00007ff6`75531069 miniruby!ruby_run_node+0x43 [C:\w\ruby\eval.c @ 320] 13 (Inline Function) --------`-------- miniruby!rb_main+0x25 [C:\w\ruby\main.c @ 42] 14 (Inline Function) --------`-------- miniruby!w32_main+0x5f [C:\w\ruby\main.c @ 62] 15 000000c6`929ffb80 00007ff6`7575e3ec miniruby!wmain+0x69 [C:\w\ruby\main.c @ 48] 16 (Inline Function) --------`-------- miniruby!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 17 000000c6`929ffbb0 00007ffa`a03de8d7 miniruby!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 18 000000c6`929ffbf0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 19 000000c6`929ffc20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 1 Id: 1e88.1468 Suspend: 1 Teb: 000000c6`9247a000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`92dff618 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`92dff620 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`92dff980 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`92dff9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 2 Id: 1e88.1058 Suspend: 1 Teb: 000000c6`9247c000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`931ff6a8 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`931ff6b0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`931ffa10 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`931ffa40 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 3 Id: 1e88.158c Suspend: 1 Teb: 000000c6`9247e000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`935ff998 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`935ff9a0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`935ffd00 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`935ffd30 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 4 Id: 1e88.3acc Suspend: 1 Teb: 000000c6`92480000 Unfrozen "ruby-timer-thread" # Child-SP RetAddr Call Site 00 000000c6`936ffbc8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`936ffbd0 00007ff6`756b7e9d KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`936ffc70 00007ffa`9e0d37b0 miniruby!timer_thread_func+0x45 [C:\w\ruby\thread_win32.c @ 777] 03 000000c6`936ffca0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 04 000000c6`936ffcd0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 05 000000c6`936ffd00 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 5 Id: 1e88.2934 Suspend: 1 Teb: 000000c6`92482000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`937ff4f8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`937ff500 00007ff6`756b1276 KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`937ff5a0 00007ff6`756f7f47 miniruby!native_cond_timedwait_ms+0x62 [C:\w\ruby\thread_win32.c @ 483] 03 (Inline Function) --------`-------- miniruby!vm_cond_wait+0x28 [C:\w\ruby\vm_sync.c @ 211] 04 000000c6`937ff5f0 00007ff6`756b2c83 miniruby!rb_vm_cond_wait+0x37 [C:\w\ruby\vm_sync.c @ 220] 05 000000c6`937ff620 00007ff6`756f7f02 miniruby!rb_ractor_sched_barrier_start+0x67 [C:\w\ruby\thread_win32.c @ 956] 06 000000c6`937ff650 00007ff6`755c7a78 miniruby!rb_vm_barrier+0x1e [C:\w\ruby\vm_sync.c @ 265] 07 (Inline Function) --------`-------- miniruby!rb_gc_vm_barrier+0x5 [C:\w\ruby\gc.c @ 179] 08 (Inline Function) --------`-------- miniruby!gc_enter+0x25 [C:\w\ruby\gc\default\default.c @ 6609] 09 000000c6`937ff680 00007ff6`755c442e miniruby!gc_start+0xc0 [C:\w\ruby\gc\default\default.c @ 6334] 0a 000000c6`937ff6e0 00007ff6`755cdd0f miniruby!garbage_collect+0x42 [C:\w\ruby\gc\default\default.c @ 6316] 0b 000000c6`937ff710 00007ff6`755c2cc3 miniruby!rb_gc_impl_start+0x4b [C:\w\ruby\gc\default\default.c @ 6767] 0c 000000c6`937ff740 00007ff6`756d5c7b miniruby!gc_start_internal+0x4f [C:\w\ruby\gc.c @ 3447] 0d 000000c6`937ff780 00007ff6`756ee237 miniruby!builtin_invoker4+0x23 [C:\w\ruby\vm_insnhelper.c @ 7373] 0e (Inline Function) --------`-------- miniruby!invoke_bf+0x32 [C:\w\ruby\vm_insnhelper.c @ 7485] 0f (Inline Function) --------`-------- miniruby!vm_invoke_builtin+0x32 [C:\w\ruby\vm_insnhelper.c @ 7493] 10 000000c6`937ff7c0 00007ff6`756e0f27 miniruby!vm_exec_core+0x27ff [C:\w\ruby\build-debug\vm.inc @ 4621] 11 (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 12 000000c6`937ff920 00007ff6`756f08b0 miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 13 (Inline Function) --------`-------- miniruby!invoke_iseq_block_from_c+0x1e3 [C:\w\ruby\vm.c @ 1651] 14 (Inline Function) --------`-------- miniruby!invoke_block_from_c_proc+0x2f2 [C:\w\ruby\vm.c @ 1745] 15 000000c6`937ffa90 00007ff6`756b6bf9 miniruby!vm_invoke_proc+0x324 [C:\w\ruby\vm.c @ 1775] 16 000000c6`937ffbd0 00007ff6`756b7987 miniruby!thread_do_start_proc+0x131 [C:\w\ruby\thread.c @ 584] 17 (Inline Function) --------`-------- miniruby!thread_do_start+0x37 [C:\w\ruby\thread.c @ 626] 18 000000c6`937ffc40 00007ff6`756b7720 miniruby!thread_start_func_2+0x243 [C:\w\ruby\thread.c @ 677] 19 000000c6`937ffe90 00007ffa`9e0d37b0 miniruby!thread_start_func_1+0x74 [C:\w\ruby\thread_win32.c @ 659] 1a 000000c6`937ffec0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 1b 000000c6`937ffef0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 1c 000000c6`937fff20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c # 6 Id: 1e88.4f4 Suspend: 1 Teb: 000000c6`92486000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`93bff768 00007ffa`a10d793e ntdll!DbgBreakPoint 01 000000c6`93bff770 00007ffa`a03de8d7 ntdll!DbgUiRemoteBreakin+0x4e 02 000000c6`93bff7a0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`93bff7d0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121450] [Ruby Bug#21200] Ractor spuriously hangs, segfault or errors
by Eregon (Benoit Daloze) 09 Sep '26

09 Sep '26

Issue #21200 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21200: Ractor spuriously hangs, segfault or errors https://bugs.ruby-lang.org/issues/21200 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ractor * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- For a new test `test_ractor_parallel` I added in https://github.com/ruby/etc/pull/52/files This seems a Ractor bug. Example failures: https://github.com/ruby/ruby/actions/runs/14097239052/job/39486770259?pr=12… ``` 1) Failure: TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 51588 exit 0 | [BUG] ``` https://github.com/ruby/ruby/actions/runs/14094646363/job/39479353266?pr=12… ``` TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 47346 exit 0 | [BUG] pthread_mutex_lock: Invalid argument (EINVAL) | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-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 ----------------------------------------------- | | | -- Threading information --------------------------------------------------- | Total ractor count: 1 | Ruby thread count for this ractor: 0 | | -- C level backtrace information ------------------------------------------- | [BUG] Segmentation fault at 0xfffffffffffffff8 | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-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. | | Crashed while printing bug report | [IMPORTANT] | Don't forget to include the Crash Report log file under | DiagnosticReports directory in bug reports. | ``` https://github.com/ruby/ruby/actions/runs/14069270994/job/39402894235#step:… ``` 1) Error: TestEtc#test_ractor_parallel: Test::Unit::ProxyError: execution of Test::Unit::CoreAssertions#assert_separately expired timeout (10 sec) pid 145797 killed by SIGKILL (signal 9) | /home/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178:in 'TestEtc#test_ractor_parallel' ``` The test has been disabled for now in https://github.com/ruby/ruby/pull/12992. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111960] [Ruby master Bug#19364] Issue with tracepoint enable/disable across ractors
by luke-gru (Luke Gruber) 09 Sep '26

09 Sep '26

Issue #19364 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19364: Issue with tracepoint enable/disable across ractors https://bugs.ruby-lang.org/issues/19364 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This sometimes segfaults: ```ruby def test_enable_disable_in_multiple_ractors_with_target rs = [] 100.times do |i| # setup new iseqs Kernel.define_method :"my_method_to_change_for_tracing_#{i}" do true end end 100.times do |i| rs << Ractor.new(i) do |j| meth = :"my_method_to_change_for_tracing_#{j}" tp = TracePoint.new(:line) { } # local to ractor 100.times do tp.enable(target: method(meth)) # change iseq internals of given method, should be done with lock tp.disable # disable hooks should hold lock too, changes method definition internals end end end rs.each(&:take) # shouldn't raise end test_enable_disable_in_multiple_ractors_with_target() ``` Changing iseq internals is done without the VM lock. This is true in Tracepoint#enable and Tracepoint#disable methods. I have a patch coming. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116061] [Ruby master Bug#20158] Ractor affects Coverage results
by janosch-x 09 Sep '26

09 Sep '26

Issue #20158 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Bug #20158: Ractor affects Coverage results https://bugs.ruby-lang.org/issues/20158 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have a large rspec test suite. I found that if I call a Ractor, the Coverage results are strongly affected, i.e. almost all files appear to be uncovered. This happens even if I only ever call a Ractor before the library or rspec are required. Unfortunately, I was not able to build a simple repro yet. I assume it is a timing thing and only affects larger suites, or it only happens if there are multiple files, and maybe if the library lazily requires its sub-modules? However, I guess this should produce the same results when added to the spec_helper.rb of other large suites: ```ruby # Ractor.new { nil } # uncomment this to affect coverage results require 'coverage' Coverage.start # require library, set up rspec etc. RSpec.configuration.after(:suite) do # this number is greatly reduced and unstable when calling Ractor above p Coverage.result.values.sum { |arr| arr.sum(&:to_i) } end ``` I had this problem in [this library](https://github.com/jaynetics/character_set/). The problem affects simplecov users as well, as described [here](https://github.com/simplecov-ruby/simplecov/issues/1058). -- https://bugs.ruby-lang.org/

4 5

[ruby-core:121941] [Ruby Bug#21315] Finalizers violate the `rb_ractor_confirm_belonging` assertion
by byroot (Jean Boussier) 09 Sep '26

09 Sep '26

Issue #21315 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21315: Finalizers violate the `rb_ractor_confirm_belonging` assertion https://bugs.ruby-lang.org/issues/21315 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Reproduction (with assertions enabled): ```ruby require "tempfile" Ractor.new do 10.times do Tempfile.new end end.take GC.start ``` ``` <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:375> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:2 ruby 3.5.0dev (2025-05-09T15:51:24Z pull/13291/merge e289a1dc58) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0007 s:0025 e:000024 METHOD /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387 [FINISH] c:0004 p:0022 s:0020 e:000019 METHOD /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :parse_lex_file c:0002 p:0006 s:0007 e:000006 BLOCK /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'block in test_parse_lex_file' /home/runner/work/ruby/ruby/src/test/prism/ractor_test.rb:26:in 'parse_lex_file' /home/runner/work/ruby/ruby/src/lib/prism/parse_result.rb:833:in 'initialize' /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387:in 'call' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/runner/work/ruby/ruby/build/ruby(rb_print_backtrace+0x14) [0x561441aeedbf] ../src/vm_dump.c:843 /home/runner/work/ruby/ruby/build/ruby(rb_vm_bugreport) ../src/vm_dump.c:1175 /home/runner/work/ruby/ruby/build/ruby(bug_report_end+0x0) [0x561441aa3f39] ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(rb_bug_without_die_internal) ../src/error.c:1097 /home/runner/work/ruby/ruby/build/ruby(die+0x0) [0x5614416e237f] ../src/error.c:1115 /home/runner/work/ruby/ruby/build/ruby(rb_bug) ../src/error.c:1117 /home/runner/work/ruby/ruby/build/ruby(rb_ractor_confirm_belonging+0xde) [0x56144188c6be] ../src/ractor_core.h:376 /home/runner/work/ruby/ruby/build/ruby(vm_exec_core+0xef) [0x5614418b23ef] /home/runner/work/ruby/ruby/build/vm.inc:2500 /home/runner/work/ruby/ruby/build/ruby(rb_vm_exec+0x156) [0x5614418a4676] ../src/vm.c:2618 /home/runner/work/ruby/ruby/build/ruby(vm_call0_cc+0x13d) [0x5614418aa1dd] ../src/vm_eval.c:101 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call0+0x4c) [0x5614418b1cc5] ../src/vm_eval.c:61 /home/runner/work/ruby/ruby/build/ruby(rb_vm_call_kw) ../src/vm_eval.c:326 /home/runner/work/ruby/ruby/build/ruby(rb_check_funcall_default_kw) ../src/vm_eval.c:694 /home/runner/work/ruby/ruby/build/ruby(rb_gc_run_obj_finalizer+0x1cf) [0x56144170220f] ../src/gc.c:306 /home/runner/work/ruby/ruby/build/ruby(rb_multi_ractor_p+0x0) [0x56144170246f] ../src/gc/default/default.c:2820 /home/runner/work/ruby/ruby/build/ruby(rb_vm_lock_enter) ../src/vm_sync.h:74 /home/runner/work/ruby/ruby/build/ruby(rb_gc_vm_lock) ../src/gc.c:137 /home/runner/work/ruby/ruby/build/ruby(finalize_list) ../src/gc/default/default.c:2843 /home/runner/work/ruby/ruby/build/ruby(finalize_deferred_heap_pages) ../src/gc/default/default.c:2866 ``` I think it wouldn't be hard to disable that check when running a finalizer, but I don't know if it's the correct thing to do. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:112091] [Ruby master Bug#19387] Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor
by luke-gru (Luke Gruber) 09 Sep '26

09 Sep '26

Issue #19387 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19387: Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor https://bugs.ruby-lang.org/issues/19387 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do receive # block, the problem is not the termination of the ractor but the starting end ObjectSpace.each_object(IO) { |io| p io # we get no objects } ``` -- https://bugs.ruby-lang.org/

6 9