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

[ruby-core:126187] [Ruby Bug#22216] Regexp backref and IO lastline are incompatible with Ractor
by headius (Charles Nutter) 10 Sep '26

10 Sep '26

Issue #22216 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #22216: Regexp backref and IO lastline are incompatible with Ractor https://bugs.ruby-lang.org/issues/22216 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem Several Regexp-matching methods currently write (and sometimes read) the implicit "backref" `$~` variable in the local frame (and related variables like `$'`). Several IO methods read or write the "last line" `$_` variable in the same way. In both cases, the result is a mutable object, which makes these variables already problematic for ractors. Making matters worse, the frame might be shared if a proc is captured and used across threads or ractors, and there's no static way to inspect a piece of code to know if it expects to read or write these variables. Where procs can be rejected by a proc for accessing captured state, there's no such check possible for these variables. All of these facts make the backref and lastline variables fundamentally incompatible with Ractor. ## Possible remedies A wholesale removal of these variables would solve the problem, but there's a lot of code that depends on them... much of that code without even realizing it, since they might not access the variables directly. In some cases, the dependencies are internal and part of the behavior of core methods. Hard errors when using methods that read or write these variables would avoid introducing threading problems into a Ractor, but would also break a large number of commonly-used methods. There have been experiments to make these variables both frame and thread-local, but they have never been made standard. Updates to backref and lastline are visible across threads and already can lead to concurrency issues even on CRuby. Deprecating the implicit behavior and making it opt-in (or opt-out?), perhaps with keyword arguments or file pragmas, might be a halfway measure. It would probably not be an easy transition. I don't know the right path forward, but I believe this issue needs to be discussed. ## JRuby perspective We continue to mimic CRuby behavior, which has led to our users occasionally running into issues when a proc accesses these variables across threads. Our recommendation: "don't do that". We also have had our frustrations optimizing around these variables, since they implicitly require access across calls. Because we cannot statically detect when they will be used, we essentially treat all method names that might *potentially* access them as deopt triggers. It's not ideal. I'd like to hear ideas for how to make these variables less "magic", less implicit and easier to deal with across calls (and across threads/ractors). -- https://bugs.ruby-lang.org/

6 22

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

10 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:125877] [Ruby Feature#22134] Faster rb_scan_args() for keyword args (optimization)
by luke-gru (Luke Gruber) 10 Sep '26

10 Sep '26

Issue #22134 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22134: Faster rb_scan_args() for keyword args (optimization) https://bugs.ruby-lang.org/issues/22134 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Motivation When using the `rb_scan_args()` API, often we want to find a value for a given keyword argument. In order to do this, we call `rb_scan_args()` like so: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:", &str, &kwargs); // duplicates the kwargs hash in argv if (!NIL_P(kwargs)) rb_get_kwargs(kwargs, &id_example, 0, 1, &example); // mutates the duplicated kwargs hash to retrieve `example:` ``` This duplicates the keyword args hash given in `argv`. It would be nice to be able to grab a direct reference to the keyword hash and to have a variant of `rb_get_kwargs()` that didn't mutate the passed in hash. ## Proposal Add a new valid format character for `rb_scan_args()`: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:^", &str, &kwargs); // access kwargs directly from argv if (!NIL_P(kwargs)) rb_get_kwargs_const(kwargs, &id_example, 0, 1, &example); // don't mutate the passed kwargs hash ``` This '^' character would only be valid after a ":'. I have a [pull request](https://github.com/ruby/ruby/pull/17558) available for anyone that is interested. Thank you! -- https://bugs.ruby-lang.org/

2 4

[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:124711] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching
by synacker (Mikhail Milovidov) 09 Sep '26

09 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 11

[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) 08 Sep '26

08 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) 08 Sep '26

08 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 08 Sep '26

08 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) 08 Sep '26

08 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