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

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 17 Sep '26

17 Sep '26

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 14 Sep '26

14 Sep '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:117750] [Ruby master Bug#20464] Redundant returns are unreachable in coverage
by kddnewton (Kevin Newton) 14 Sep '26

14 Sep '26

Issue #20464 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20464: Redundant returns are unreachable in coverage https://bugs.ruby-lang.org/issues/20464 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- With the following code: ```ruby def meth_return(a) return if a return end ``` If you run coverage on it, it's not possible for it to hit line 3, because there isn't a line event, because the return node was eliminated from the AST before it was compiled. There is a `putnil` instruction, so it's possible for us to attach a line event for it, but the compiler doesn't today. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 14 Sep '26

14 Sep '26

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 10

[ruby-core:123306] [Ruby Bug#21612] Make sure we never context switch while holding the VM lock
by luke-gru (Luke Gruber) 14 Sep '26

14 Sep '26

Issue #21612 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21612: Make sure we never context switch while holding the VM lock https://bugs.ruby-lang.org/issues/21612 * Author: luke-gru (Luke Gruber) * Status: Open * Target version: 3.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## The Problem We're seeing errors in our application that uses ractors. The errors look like: ``` [BUG] unexpected situation - recordd:1 current:0 error.c:1097 rb_bug_without_die_internal vm_sync.c:275 disallow_reentry eval_intern.h:136 rb_ec_vm_lock_rec_check eval_intern.h:147 rb_ec_tag_state vm.c:2619 rb_vm_exec vm.c:1702 rb_yield eval.c:1173 rb_ensure ``` We concluded that there was context switching going on while a thread held the VM lock. During the investigation into the issue, we added assertions in the code that we never yield to another thread with the VM lock held. We enabled these VM lock assertions even in single ractor mode. These assertions were failing in a few places, but most notably in finalizers. Finalizers are running with the VM lock held, and they were context switching and causing this issue. ## Why Is This Bad? There are a few reasons we shouldn't be able to context switch while holding the VM lock. In single-ractor mode with threads A and B: 1) Anything in this critical section should be thought of as a transaction related to the memory that's changed inside. if A has the lock, manipulates some global memory and yields to B with the lock still taken and without finishing the memory updates and then B takes it and starts writing to the same memory, the state of this global memory could be corrupted. Currently we don't actually take the VM lock in single-ractor mode, but that doesn't mean these issues can't happen. Yielding to another thread in the middle of manipulating global memory *can* still happen and it causes similar issues. In multi-ractor mode with ractors A and B: 1) We get the same issues as in single-ractor mode. 2) We can also get deadlocks if A has the lock, yields to B and B is blocked waiting on the lock. Unfortunately, many things can cause context switching in Ruby, so what is safe to call when the VM lock is taken? ## Guidelines I've come up with some guidelines. With the VM lock held, You should be able to: * Create ruby objects, call `ruby_xmalloc`, etc. * Jump using `EC_JUMP_TAG`. The lock will automatically be unlocked depending on how far up the call stack you locked it and where you're jumping to. * Check ruby interrupts. Since jumping can pop ruby frames and popping frames checks interrupts, you are allowed. It should never context switch with the VM lock held, even if the ruby thread's quantum is up. You shouldn't be able to: * Call any ruby method or enter Ruby's VM loop. For example, `rb_funcall` is not allowed, nor is `rb_warn` (it can call ruby code). `rb_sprintf` is not allowed because it can call `rb_inspect`. * Call `rb_nogvl` * Enter any blocking operation managed by Ruby. * Call a ruby-level mechanism that can context switch, like `rb_mutex_lock`. ## The Fix Of course, unlocking during finalizers is the main fix but there are other places that also need unlocking. I think adding assertions that the VM lock is not held will be important in finding these bugs and not creating regressions in the future. We don't have to add lots of these, just in a few places. These assertions, which only run in debug mode, should also run when in single-ractor mode. ## Future Work I think some documentation would be helpful for what is and isn't allowed while holding the VM lock and other locks in the cruby source. I am currently working on a `Concurrency Guide` for cruby developers that includes this info. It will not go over every lock, just the VM lock and the "all other locks" category. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116041] [Ruby master Bug#20155] Using value of rb_fiber_scheduler_current() crashes Ruby
by paddor (Patrik Wenger) 14 Sep '26

14 Sep '26

Issue #20155 has been reported by paddor (Patrik Wenger). ---------------------------------------- Bug #20155: Using value of rb_fiber_scheduler_current() crashes Ruby https://bugs.ruby-lang.org/issues/20155 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While trying to manually block/unblock fibers from an extension using the Fiber Scheduler, I noticed that using the return value of `rb_fiber_scheduler_current()` crashes Ruby. I've created a minimal extension gem called "fiber_blocker". Its test suite shows the behavior. See https://github.com/paddor/fiber_blocker, especially the lines containing `FIXME`. Passing `Fiber.scheduler` to the extension functions works. But letting it get the current scheduler itself does not seem to work. Is `rb_fiber_scheduler_current()` not the equivalent to `Fiber.scheduler`? Even just printing the its return value with `#p` will crash Ruby. Ruby either crashes like this: ``` # Running: T1 BEGIN T2 BEGIN T1 END ..T1 BEGIN ext: blocking fiber passed scheduler = #<Scheduler:0x00007fc5f22d39e8 @readable={}, @writable={}, @waiting={}, @closed=false, @lock=#<Thread::Mutex:0x00007fc5f22ec8d0>, @blocking={}, @ready=[], @urgent=[#<IO:fd 5>, #<IO:fd 6>]> T2 BEGIN ext: unblocking fiber T1 END .E Finished in 1.007014s, 3.9721 runs/s, 2.9791 assertions/s. 1) Error: TestFiberBlocker#test_fiber_blocker_current_fiber: fatal: machine stack overflow in critical region No backtrace ``` Or with a segfault: ``` # Running: FiberBlocker.test works. .T1 BEGIN T2 BEGIN T1 END .T1 BEGIN ext: blocking fiber /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40: [BUG] Segmentation fault at 0x00000000390d8f98 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 CFUNC :block_fiber c:0002 p:0014 s:0006 e:000005 BLOCK /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block in test_fiber_blocking_in_ext' /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block_fiber' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 4 -- Machine register context ------------------------------------------------ RIP: 0x00007f1554f17ad8 RBP: 0x00000000390d8f90 RSP: 0x00007f153a79e280 RAX: 0x00007f1554addba8 RBX: 0x00007f153a79eab0 RCX: 0x0000000000000000 RDX: 0x00007f1554ade600 RDI: 0x00007f15551e8788 RSI: 0x0000000000000ae1 R8: 0x000000000000002b R9: 0x00007f153a79f038 R10: 0x00007f1554c0b9b0 R11: 0x00007f153a79e490 R12: 0x0000000000000ae1 R13: 0x0000000000000000 R14: 0x0000000000000000 R15: 0x000055ab732d7df0 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_print_backtrace+0x14) [0x7f1554f24961] /home/user/src/ruby-3.3.0/vm_dump.c:820 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_bugreport) /home/user/src/ruby-3.3.0/vm_dump.c:1151 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0x104) [0x7f1554d1c214] /home/user/src/ruby-3.3.0/error.c:1065 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(sigsegv+0x4f) [0x7f1554e700df] /home/user/src/ruby-3.3.0/signal.c:926 /lib/x86_64-linux-gnu/libc.so.6(0x7f1554842520) [0x7f1554842520] /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_CLASS+0x0) [0x7f1554f17ad8] ./include/ruby/internal/globals.h:178 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(gccct_method_search) /home/user/src/ruby-3.3.0/vm_eval.c:475 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv_scope) /home/user/src/ruby-3.3.0/vm_eval.c:1063 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv) /home/user/src/ruby-3.3.0/vm_eval.c:1084 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_inspect+0x19) [0x7f1554dc1569] /home/user/src/ruby-3.3.0/object.c:697 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby__sfvextra+0x11a) [0x7f1554e7223a] /home/user/src/ruby-3.3.0/sprintf.c:1119 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(BSD_vfprintf+0xa69) [0x7f1554e73059] /home/user/src/ruby-3.3.0/vsnprintf.c:830 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_SET_CLASS_RAW+0x0) [0x7f1554e75b56] /home/user/src/ruby-3.3.0/sprintf.c:1168 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby_vsprintf0) /home/user/src/ruby-3.3.0/sprintf.c:1169 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_enc_vsprintf+0x5d) [0x7f1554e75ecd] /home/user/src/ruby-3.3.0/sprintf.c:1195 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_sprintf+0x9d) [0x7f1554e7607d] /home/user/src/ruby-3.3.0/sprintf.c:1225 /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/lib/fiber_blocker/fiber_blocker.so(block_fiber+0x4a) [0x7f1554ad430a] ../../../../ext/fiber_blocker/fiber_blocker.c:29 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_cfp_consistent_p+0x0) [0x7f1554ef64b4] /home/user/src/ruby-3.3.0/vm_insnhelper.c:3490 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame_) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3492 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3518 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_other) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3544 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_sendish+0x9e) [0x7f1554f06f87] /home/user/src/ruby-3.3.0/vm_insnhelper.c:5581 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_exec_core) /home/user/src/ruby-3.3.0/insns.def:834 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_exec+0x19a) [0x7f1554f0d1fa] /home/user/src/ruby-3.3.0/vm.c:2486 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_invoke_proc+0x5f) [0x7f1554f12e0f] /home/user/src/ruby-3.3.0/vm.c:1728 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_fiber_start+0x1ba) [0x7f1554cf098a] /home/user/src/ruby-3.3.0/cont.c:2536 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(fiber_entry+0x20) [0x7f1554cf0d00] /home/user/src/ruby-3.3.0/cont.c:847 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_threadptr_root_fiber_setup) (null):0 ``` I hope I'm not missing something obvious. My C isn't very good. -- https://bugs.ruby-lang.org/

2 12

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