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

[ruby-core:127098] [Ruby Bug#22435] Autoload under a Fiber scheduler causes a deadlock or [BUG]
by mame (Yusuke Endoh) 14 Oct '26

14 Oct '26

Issue #22435 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22435: Autoload under a Fiber scheduler causes a deadlock or [BUG] https://bugs.ruby-lang.org/issues/22435 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code causes a deadlock. test/fiber/scheduler.rb is the one in the ruby/ruby repository (https://github.com/ruby/ruby/blob/master/test/fiber/scheduler.rb) ```ruby # fs-autoload-deadlock.rb require_relative "test/fiber/scheduler" class MyScheduler < Scheduler def blocking_operation_wait(work) @workers ||= Fiber.blocking { Etc.nprocessors } # lazily size a worker pool super end end autoload :Etc, "etc" autoload :JSON, "json" $LOADED_FEATURES << "dummy" # force to rebuild the index of $LOADED_FEATURES Thread.new do Fiber.set_scheduler(MyScheduler.new) Fiber.schedule { p JSON } end.join ``` ``` $ ruby fs-autoload-deadlock.rb #<Thread:0x00007ce4cf1eed90 fs-autoload-deadlock.rb:14 run> terminated with exception (report_on_exception is true): fs-autoload-deadlock.rb:5:in 'block in MyScheduler#blocking_operation_wait': deadlock; recursive locking (ThreadError) from fs-autoload-deadlock.rb:5:in 'Fiber.blocking' from fs-autoload-deadlock.rb:5:in 'MyScheduler#blocking_operation_wait' from fs-autoload-deadlock.rb:16:in 'block (2 levels) in <main>' ... ``` Also, the following code causes [BUG]. ```ruby # fs-autoload-segv.rb require_relative "test/fiber/scheduler" class MyScheduler < Scheduler def block(blocker, timeout = nil) blocker.inspect #=> [BUG] Segmentation fault at 0x0000000000000000 super end end autoload :JSON, "json" $LOADED_FEATURES << "dummy" # force to rebuild the index of $LOADED_FEATURES Thread.new do Fiber.set_scheduler(MyScheduler.new) Fiber.schedule { JSON } Fiber.schedule { JSON } end.join ``` ``` $ ruby fs-autoload-segv.rb fs-autoload-segv.rb:5: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.1.0dev (2026-08-21T07:50:27Z master c9e9101403) +PRISM [x86_64-linux] ... -- Ruby level backtrace information ---------------------------------------- fs-autoload-segv.rb:16:in 'block (2 levels) in <main>' fs-autoload-segv.rb:5:in 'block' ... ``` Both reproduce on master and 4.0.6. `$LOADED_FEATURES << "dummy"` is to make Ruby rebuild the index of `$LOADED_FEATURES` (stat(2) during the rebuild calls `blocking_operation_wait`). ## Cause The cause is the autoload mutex introduced by commit:32de6097b2b5d8394b3a1399e13d309444697954 (https://github.com/ruby/ruby/pull/5898) The deadlock above occurs because this mutex is locked recursively. Also, when a fiber blocks on locking the mutex, the mutex is passed to `Fiber::Scheduler#block` as the blocker, but it is a hidden object, which leads to rb_bug. ## Analysis Let me recap the problem that commit:32de6097b2 tried to solve, [Bug #18782]. Autoload roughly proceeded in the following steps 1, 2, and 3. 1. If the mutex to synchronize requiring the feature has already been created and another thread is locking it, wait, because that thread is requiring the feature 2. If the feature has not been required yet, create a mutex for the feature, lock it, and require the feature 3. Refer to the constant that should have been defined Consider the following code. ```ruby autoload :Foo, "foobar.rb" autoload :Bar, "foobar.rb" tA = Thread.new {Foo} tB = Thread.new {Bar} ``` If tA and tB executed the steps 1, 2, and 3 in the following order, a NameError was raised in the thread tA. * tA: executes step 1 (there is no mutex, so it proceeds without waiting) * context switch * tB: executes step 1 (there is no mutex, so it proceeds without waiting) * tB: executes step 2 (creates and locks the mutex, and requires the feature. When the require finishes, the feature is marked as required, but the autoload constants are defined after that) * context switch * tA: executes step 2 (the feature has been required, so it does nothing) * tA: executes step 3 (the constant is not defined yet, so NameError) The check in step 2, whether the feature has not been required yet, may call `to_str` of an element of `$LOADED_FEATURES` or release the GVL, so a context switch can occur there. ## Solution commit:32de6097b2 tried to solve it by adding a new mutex to lock the steps 1, 2, and 3 of autoload, but as shown above, this is a new source of deadlocks and adds complexity, so I don't think it is good. I think it can be solved simply by swapping the steps 1 and 2 of autoload. 1'. If the feature has not been required yet, create a mutex for the feature, lock it, and require the feature 2'. If the mutex to synchronize requiring the feature has already been created and another thread is locking it, wait, because that thread is requiring the feature 3. Refer to the constant that should have been defined The thread that requires the feature keeps the mutex locked until it finishes defining the constants. So, if the feature looks "required" at 1' but the constants are not defined yet, the mutex is still locked at 2', and the thread waits for it. Also, even if both threads see the feature as not required yet at 1', only one mutex is created. Checking whether the mutex exists and creating it involve no Ruby code nor GVL release, so no thread switch occurs between them thanks to the GVL. The thread that comes later finds the mutex created by the other, and waits for it. This solves the NameError problem of [Bug #18782] without the global autoload mutex. So, how about removing the global autoload mutex introduced by commit:32de6097b2, and swapping the steps as above? PR: https://github.com/ruby/ruby/pull/19335 In addition to passing all Ruby tests, I also checked the tests of zeitwerk and bootsnap just in case. All tests of zeitwerk pass. One test of bootsnap (`test_load_static_libaries`) fails, but it is because prism is no longer a default gem on master, and it is unrelated to this change. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127096] [Ruby Bug#22434] "No live threads left. Deadlock?" when running system() or spawn in Ractors
by jhawthorn (John Hawthorn) 13 Oct '26

13 Oct '26

Issue #22434 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #22434: "No live threads left. Deadlock?" when running system() or spawn in Ractors https://bugs.ruby-lang.org/issues/22434 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: REQUIRED ---------------------------------------- Non-main Ractors don't support `fork()`, but do support `system()` and `spawn()`. They can end up deadlocked inside the prefork method when trying to flush stdio. ``` $stdout = File.open(File::NULL, "w") writer = Thread.new { loop { $stdout.write("x" * 100 + "\n"); $stdout.flush } } r = Ractor.new { 500.times { system("true") }; :done } raise unless :done == r.value writer.kill.join ``` ``` ❯ ruby -v test.rb ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin25] test.rb:3: warning: Ractor API is experimental and may change in future versions of Ruby. #<Thread:0x000000010c1f62a8 run> terminated with exception (report_on_exception is true): test.rb:3:in 'Kernel#system': No live threads left. Deadlock? (fatal) 1 threads, 1 sleeps current:0x00000007e696b800 main thread:0x00000007e696b800 * #<Thread:0x000000010c1f62a8 sleep_forever> rb_thread_t:0x00000007e696b800 native:0x000000016bcef000 int:0 test.rb:3:in 'Kernel#system' test.rb:3:in 'block (2 levels) in <main>' test.rb:3:in 'Integer#times' test.rb:3:in 'block in <main>' ... ``` https://github.com/ruby/ruby/pull/19321 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127063] [Ruby Bug#22424] IO#readpartial and IO#sysread should respect IO#timeout= value
by rhenium (Kazuki Yamaguchi) 13 Oct '26

13 Oct '26

Issue #22424 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22424: IO#readpartial and IO#sysread should respect IO#timeout= value https://bugs.ruby-lang.org/issues/22424 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- I expected `IO#readpartial` and `IO#sysread` to respect `IO#timeout=` and raise `IO::TimeoutError`, but they currently ignore it and block indefinitely: ```ruby IO.pipe{|r,w|r.timeout=1; r.read(1)} # raises IO::TimeoutError after 1 second, as expected IO.pipe{|r,w|r.timeout=1; r.gets(1)} # raises IO::TimeoutError after 1 second, as expected IO.pipe{|r,w|r.timeout=1; r.sysread(1)} # blocks indefinitely IO.pipe{|r,w|r.timeout=1; r.readpartial(1)} # blocks indefinitely ``` This appears to be a simple omission in commit:e4f91bbdbaa6ab3125f24967414ac5300bb244f5 (the original commit that added `IO#timeout=`, [Feature #18630]). -- https://bugs.ruby-lang.org/

1 1

[ruby-core:127092] [Ruby Bug#22433] IO#sysread and IO#pread are inconsistent for length 0 and negative numbers
by rhenium (Kazuki Yamaguchi) 13 Oct '26

13 Oct '26

Issue #22433 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #22433: IO#sysread and IO#pread are inconsistent for length 0 and negative numbers https://bugs.ruby-lang.org/issues/22433 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When the length is 0 and an output buffer is given, the buffer is not cleared correctly. [Bug #18421] fixed the same bug for `IO#readpartial` and `IO#read_nonblock`, but it omitted `IO#sysread` and `IO#pread`: ```ruby File.open("/dev/null"){|f|f.read(0,"abc")} #=> "" # Returns the buffer unmodified File.open("/dev/null"){|f|f.sysread(0,"abc")} #=> "abc" File.open("/dev/null"){|f|f.pread(0,0,"abc")} #=> "abc" ``` These methods should also reject negative lengths: ```ruby File.open("/dev/null"){|f|f.read(-1,"abc")} # ArgumentError "negative length -1 given" # Tries to read (size_t)-1 bytes File.open("/dev/null"){|f|f.sysread(-1,"abc")} # Errno::EFAULT File.open("/dev/null"){|f|f.pread(-1,0,"abc")} # Errno::EFAULT ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:127067] [Ruby Bug#22426] ZJIT: keyword arguments swapped when passed out of declared order to a method with a block (please backport d81a11d4e6 to 4.0)
by incubus (Alexander Logvinov) 13 Oct '26

13 Oct '26

Issue #22426 has been reported by incubus (Alexander Logvinov). ---------------------------------------- Bug #22426: ZJIT: keyword arguments swapped when passed out of declared order to a method with a block (please backport d81a11d4e6 to 4.0) https://bugs.ruby-lang.org/issues/22426 * Author: incubus (Alexander Logvinov) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello! On Ruby 4.0.7 with ZJIT enabled, keyword arguments can reach the wrong parameters after the method is compiled. It happens when the caller passes keywords in a different order than the callee declares them, and the callee body contains a block. The values are swapped silently, so the result is wrong data, not a crash. We hit this in a staging environment through the jwt gem (3.3.0). JWT::Encode#segments calls @token.sign!(algorithm: @algorithm, key: @key), while JWT::Token#sign! is declared as def sign!(key:, algorithm:) and calls .tap do ... end in its body. After about 30 calls, JWT::JWA.resolve receives the OpenSSL::PKey::EC key instead of the 'ES256' string and raises ArgumentError: Custom algorithms are required to include JWT::JWA::SigningAlgorithm. Reproduction (no gems): ``` ruby # frozen_string_literal: true module JWA Signer = Struct.new(:algorithm, :key) def self.create_signer(algorithm:, key:) raise ArgumentError, "algorithm=#{algorithm.inspect}" unless algorithm.is_a?(String) Signer.new(algorithm, key) end end class Token def sign!(key:, algorithm:) JWA.create_signer(algorithm: algorithm, key: key).tap do |signer| @signature = signer.key end nil end end 100.times do |i| Token.new.sign!(algorithm: 'ES256', key: :the_key) rescue ArgumentError => e puts "FAIL at #{i}: #{e.message}"; exit 1 end puts 'OK' ``` Results: ``` $ ruby test.rb # 4.0.7, interpreter OK $ ruby --yjit test.rb # 4.0.7 OK $ ruby --zjit test.rb # 4.0.7 FAIL at 29: algorithm=:the_key $ ./miniruby --zjit test.rb # master 46033eff6c (2026-10-11) OK ``` The bug needs both conditions. With the same keyword order on both sides, or without the block in sign!, the script prints OK on 4.0.7 with --zjit too. This looks like the bug reported in https://github.com/Shopify/ruby/issues/922 and fixed on master by https://github.com/ruby/ruby/pull/15827 ("ZJIT: Spill stack from direct send with args in callee order", commit d81a11d4e61f67b6fb0aaa44aaa7ead4022148dd). That commit is not in v4.0.7, and I could not find it on the ruby_4_0 branch. Could d81a11d4e6 be backported to Ruby 4.0? The jwt failure was seen on x86_64-linux; the minimal reproduction above was run on arm64-darwin (ruby 4.0.7 +PRISM [arm64-darwin27]). Thank you! -- https://bugs.ruby-lang.org/

2 2

[ruby-core:127019] [Ruby Bug#22419] [BUG] "rb_objspace_reachable_objects_from_local: set is owned by another Ractor" when a non-main Ractor reads a class instance variable since f0439cdfa7
by yahonda (Yasuo Honda) 13 Oct '26

13 Oct '26

Issue #22419 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22419: [BUG] "rb_objspace_reachable_objects_from_local: set is owned by another Ractor" when a non-main Ractor reads a class instance variable since f0439cdfa7 https://bugs.ruby-lang.org/issues/22419 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-06T22:31:56Z master f0439cdfa7) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The Rails nightly CI against Ruby master started crashing with `[BUG] rb_objspace_reachable_objects_from_local: set is owned by another Ractor` in Action Pack and Action View on all of master, YJIT and master-debug. It bisects to f0439cdfa7 ("Remove VM lock from Ractor.make_shareable()", https://github.com/ruby/ruby/pull/19145) reading a class instance variable that holds a frozen `Set` created on the main Ractor from a non-main Ractor crashes. The crash happens where a non-main Ractor reads class-level state such as `AbstractController::Base.action_methods` (a frozen `Set` memoized in a class instance variable) and `Mime::Type`'s registry: https://buildkite.com/rails/rails-nightly/builds/4809#01a11d51-060e-49c8-bd… The full log of that Action Pack job is attached (rails-nightly_build_4809_actionpack-master.log.zip). It can be reproduced with a single Action Pack test: ``` cd actionpack && bin/test test/controller/base_test.rb -i test_action_methods_is_ractor_safe_by_default ``` ## Steps to reproduce ```ruby class C @s = Set[1, 2].freeze class << self; attr_reader :s; end end p Ractor.new { C.s.include?(1) }.value ``` ## Expected behavior ``` $ ruby -v ruby 4.1.0dev (2026-10-06T21:11:37Z master e8964f3aa3) +PRISM [x86_64-linux] $ ruby rep.rb rep.rb:5: warning: Ractor API is experimental and may change in future versions of Ruby. true ``` ## Actual behavior ``` $ ruby -v ruby 4.1.0dev (2026-10-06T22:31:56Z master f0439cdfa7) +PRISM [x86_64-linux] $ ruby rep.rb rep.rb:5: warning: Ractor API is experimental and may change in future versions of Ruby. rep.rb:5: [BUG] rb_objspace_reachable_objects_from_local: set is owned by another Ractor ruby 4.1.0dev (2026-10-06T22:31:56Z master f0439cdfa7) +PRISM [x86_64-linux] -- Ruby level backtrace information ---------------------------------------- rep.rb:5:in 'block in <main>' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ruby(rb_print_backtrace+0x11) vm_dump.c:1117 ruby(rb_vm_bugreport) vm_dump.c:1483 ruby(rb_bug_without_die_internal+0xbe) error.c:1150 ruby(rb_bug) error.c:1168 ruby(...) gc.c:5948 ruby(obj_traverse_reachable+0x2b) ractor.c:1687 ruby(obj_traverse_i) ractor.c:1825 ruby(rb_obj_traverse+0x2c) ractor.c:1875 ruby(rb_ractor_shareable_p_continue) ractor.c:2081 ruby(rb_ractor_shareable_p+0x1b) ./include/ruby/ractor.h:280 ruby(rb_ractor_shareable_p) ./include/ruby/ractor.h:269 ruby(rb_ivar_lookup) variable.c:1626 ruby(vm_sendish+0xae) vm_insnhelper.c:6285 ... ``` ---Files-------------------------------- rails-nightly_build_4809_actionpack-master.log.zip (168 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:127073] [Ruby Bug#22427] `--enable=zjit` does not enable ZJIT
by znz (Kazuhiro NISHIYAMA) 12 Oct '26

12 Oct '26

Issue #22427 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #22427: `--enable=zjit` does not enable ZJIT https://bugs.ruby-lang.org/issues/22427 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Assignee: jit * ruby -v: ruby 4.1.0dev (2026-10-11T13:56:36Z v4.1.0-preview1 2d08b5f42f) +PRISM [x86_64-linux] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- `ruby --help` lists `zjit` under "Features" (`zjit Method-based JIT compiler (default: disabled).`), but `--enable=zjit` alone does not enable ZJIT, while `--enable=yjit` does enable YJIT. ``` $ ruby -v ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] $ ruby --enable=yjit -v ruby 4.0.7 (2026-09-15 revision 229531a6cf) +YJIT +PRISM [x86_64-linux] $ ruby --enable=yjit -e 'p RubyVM::YJIT.enabled?' true $ ruby --enable=zjit -v ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] $ ruby --enable=zjit -e 'p RubyVM::ZJIT.enabled?' false $ ruby --zjit -v ruby 4.0.7 (2026-09-15 revision 229531a6cf) +ZJIT +PRISM [x86_64-linux] $ ruby --zjit -e 'p RubyVM::ZJIT.enabled?' true ``` The same happens with `--enable-zjit` and with `RUBYOPT=--enable=zjit`. ZJIT is enabled as soon as any `--zjit-*` option is added (for example `--enable=zjit --zjit-call-threshold=30`), and also with `RUBY_ZJIT_ENABLE=1`. The cause is in `ruby.c`. `--enable=zjit` only sets the feature bit. Later, `opt->zjit` is computed as ```c #if USE_ZJIT if (FEATURE_SET_P(opt->features, zjit)) { bool rb_zjit_option_enable(void); opt->zjit = rb_zjit_option_enable(); // set opt->zjit for Init_ruby_description() and calling rb_zjit_init() } #endif ``` and `rb_zjit_option_enable()` (zjit/src/options.rs) returns true only when the Rust-side `OPTIONS` has been initialized (`OPTIONS.as_ref().is_some_and(|opts| !opts.disable)`). `OPTIONS` is initialized by `rb_zjit_prepare_options()`, which is called for `--zjit*` (through `setup_zjit_options()`) and for `RUBY_ZJIT_ENABLE`, but not for `--enable=zjit`. So `opt->zjit` stays false and `rb_zjit_init(false)` is called. The YJIT counterpart, `rb_yjit_option_disable()`, has no such dependency, which is why `--enable=yjit` works. Judging from the diff, this was introduced by commit:f84bbb4238 ("ZJIT: add support for lazy `RubyVM::ZJIT.enable`", 2025-11-17, included in 4.0.0). Before it, the code was ```c if (FEATURE_SET_P(opt->features, zjit) && !opt->zjit) { extern void rb_zjit_prepare_options(void); rb_zjit_prepare_options(); opt->zjit = true; } ``` A possible fix is to prepare the options when the feature bit is set, before asking whether ZJIT should be enabled: ```c #if USE_ZJIT if (FEATURE_SET_P(opt->features, zjit)) { // --enable=zjit sets the feature bit without going through setup_zjit_options() extern void rb_zjit_prepare_options(void); rb_zjit_prepare_options(); bool rb_zjit_option_enable(void); opt->zjit = rb_zjit_option_enable(); } #endif ``` `rb_zjit_prepare_options()` already handles the already-initialized case, so `--zjit-*` options and `--zjit-disable` keep working. test/ruby/test_rubyoptions.rb does not exercise `--enable=yjit` or `--enable=zjit`, so a test for the `--enable=` form would also help. Reproduced in the `ghcr.io/ruby/ruby:4.0` (4.0.7) and `ghcr.io/ruby/ruby:master` (4.1.0dev 2d08b5f42f) Docker images (x86_64-linux). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:127081] [Ruby Bug#22430] regex counted group with a zero-width iteration misses a match
by robertmorelli (Robert Morelli) 12 Oct '26

12 Oct '26

Issue #22430 has been reported by robertmorelli (Robert Morelli). ---------------------------------------- Bug #22430: regex counted group with a zero-width iteration misses a match https://bugs.ruby-lang.org/issues/22430 * Author: robertmorelli (Robert Morelli) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- repro: ```ruby /\A(?:a|^){2}\z/.match?("a") # true /\A(?:a|^){2,3}\z/.match?("a") # false /\A(?:\B|a){3}\z/.match?("aa") # false /\A(?:^a*){2,3}\z/.match?("a") # false ``` Perl and Python return true for all four. Possibly same family as #22418. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127080] [Ruby Bug#22429] regex empty capture group in a counted loop prevents a match
by robertmorelli (Robert Morelli) 12 Oct '26

12 Oct '26

Issue #22429 has been reported by robertmorelli (Robert Morelli). ---------------------------------------- Bug #22429: regex empty capture group in a counted loop prevents a match https://bugs.ruby-lang.org/issues/22429 * Author: robertmorelli (Robert Morelli) * Status: Open * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- repro: ```ruby /\A(?:(){1,2}?a)+\z/.match?("aa") # false /\A(?:(?:){1,2}?a)+\z/.match?("aa") # true /\A(?:(){1,2}a)+\z/.match?("aa") # true ``` An empty capture `()` behaves differently from `(?:)`. Perl, Python and Oniguruma 6.9.10 return true for all three. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127079] [Ruby Bug#22428] Fiber scheduler: rb_nogvl returns as if the function ran when an offloaded operation is cancelled before execution
by watson1978 (Shizuo Fujita) 12 Oct '26

12 Oct '26

Issue #22428 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #22428: Fiber scheduler: rb_nogvl returns as if the function ran when an offloaded operation is cancelled before execution https://bugs.ruby-lang.org/issues/22428 * Author: watson1978 (Shizuo Fujita) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-12T07:31:01Z master 3edde2d2a2) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description When a fiber scheduler cancels an offloaded blocking operation before a worker starts it, `rb_nogvl` returns normally even though the function never ran. It returns the zero-initialized result, so the caller cannot distinguish the cancellation from a successful call. For example, `File.exist?` uses `IO_WITHOUT_GVL` with `RB_NOGVL_OFFLOAD_SAFE`. If the operation is cancelled before it starts, the zeroed `stat` result causes `File.exist?` to return `true` for a path that does not exist. This report concerns Ruby's handling of cancellation before execution. Ruby handles the cancellation the same way whichever scheduler cancels the operation. The io-event behavior that triggers it is described under "Related work" below. ## Reproduction ### 1. Create the C extension Save the following as `slow_op.c`. The extension sleeps without the GVL. `SlowOp.run` returns `true` only if the C function actually ran. ```c #include <ruby.h> #include <ruby/thread.h> #include <stdint.h> #include <time.h> static void * slow(void *arg) { long ms = (long)(intptr_t)arg; struct timespec ts = { ms / 1000, (ms % 1000) * 1000000L }; while (nanosleep(&ts, &ts) != 0) { } return (void *)1; } static VALUE slow_op_run(VALUE self, VALUE ms) { void *ran = rb_nogvl(slow, (void *)(intptr_t)NUM2LONG(ms), RUBY_UBF_IO, NULL, RB_NOGVL_OFFLOAD_SAFE); return ran ? Qtrue : Qfalse; } void Init_slow_op(void) { VALUE mod = rb_define_module("SlowOp"); rb_define_module_function(mod, "run", slow_op_run, 1); } ``` ### 2. Create the Ruby script Save the following as `repro.rb`. It requires the `async` gem. The script stops each task around the time its offloaded call finishes. Each task then makes another offloaded call from its `ensure` block: either `SlowOp.run(1)` or `File.exist?`, depending on `FIRST`. ```ruby require 'async' require 'slow_op' counts = Hash.new(0) Fiber.set_scheduler(Async::Scheduler.new(worker_pool: IO::Event::WorkerPool.new(maximum_worker_count: 4))) Async do |top| 300.times do tasks = Array.new(4) do task = top.async do SlowOp.run(20) ensure counts[:ensure] += 1 if ENV['FIRST'] == 'exist' counts[:exist_true_for_missing_path] += 1 if File.exist?('/nonexistent/path') else counts[:slow_op_did_not_run] += 1 unless SlowOp.run(1) end end top.async do sleep(0.0195 + (rand * 0.002)) task.stop end task end tasks.each(&:wait) end end Fiber.set_scheduler(nil) p counts ``` ### 3. Build and run Run these commands in the directory containing both files. ```sh ruby -rmkmf -e "create_makefile('slow_op')" && make FIRST=slow_op ruby -I . repro.rb FIRST=exist ruby -I . repro.rb ``` ## Expected result Both runs should print `{ensure: 1200}` with no failure counters. Every `SlowOp.run(1)` call in `ensure` should return `true`, and every `File.exist?('/nonexistent/path')` call should return `false`. ## Actual results An example run on Linux with the default selector (URing): ``` $ ruby -v ruby 4.1.0dev (2026-10-12T07:31:01Z master 3edde2d2a2) +PRISM [x86_64-linux] $ ruby -rmkmf -e "create_makefile('slow_op')" && make $ FIRST=slow_op ruby -I . repro.rb {ensure: 1200, slow_op_did_not_run: 95} $ FIRST=exist ruby -I . repro.rb {ensure: 1200, exist_true_for_missing_path: 157} ``` The table shows the number of failures out of 1,200 stopped tasks in each run. The last two columns correspond to the `FIRST=slow_op` and `FIRST=exist` runs, respectively. The counts vary from run to run. | Platform | Ruby | async / io-event | Selector | `SlowOp.run(1)` did not run | `File.exist?` true for a missing path | |---|---|---|---|---|---| | Linux x86_64 | 4.0.7 (229531a6cf) | 2.46.0 / 1.22.1 | URing | 99 | 162 | | Linux x86_64 | 4.0.7 (229531a6cf) | 2.46.0 / 1.22.1 | EPoll | 155 | 139 | | Linux x86_64 | 4.1.0dev (3edde2d2a2) | 2.46.0 / 1.22.1 | URing | 67 | 79 | | Linux x86_64 | 4.1.0dev (3edde2d2a2) | 2.46.0 / 1.22.1 | EPoll | 103 | 88 | | FreeBSD 15.0 x86_64 | 4.0.3 (85ddef263a) | 2.46.0 / 1.22.1 | KQueue | 195 | 194 | | macOS 27.2 arm64 | 4.0.6 (03b6d3f889) | 2.46.0 / 1.22.0 | KQueue | 28 | 33 | ## Cause When an operation is cancelled before execution, Ruby takes the following path. 1. `rb_fiber_scheduler_blocking_operation_cancel` changes the status from `QUEUED` to `CANCELLED` without running the function. 2. `rb_fiber_scheduler_blocking_operation_execute` sees that the status is no longer `QUEUED` and returns `-1`. The function never runs, and `state->result` remains `NULL`. 3. `rb_fiber_scheduler_blocking_operation_wait` returns the scheduler's return value for the `CANCELLED` operation. `rb_nogvl` then returns `state.result`, which is `NULL`, with `errno` set to `0`. There is a fallback for an operation that is still `QUEUED`: `rb_fiber_scheduler_blocking_operation_wait` returns `Qundef`, which causes `rb_nogvl` to run the function in place. That fallback does not apply once the status is `CANCELLED`. An operation cancelled during execution also ends as `CANCELLED`. The status alone therefore does not tell the caller whether the function ran. ## Related work `IO::Event::WorkerPool` in io-event 1.22.1 cancels a queued operation when the waiting fiber wakes up for a reason other than completion. In the reproduction, such a wakeup happens right after an Async task is stopped. The open [socketry/io-event#230](https://github.com/socketry/io-event/pull/230) changes io-event so that it does not cancel an operation on this kind of wakeup. Its description also notes that a cancelled operation can appear to succeed. That change addresses the io-event trigger; this report concerns how Ruby handles the cancellation itself. RMagick works around this in [rmagick/rmagick#1930](https://github.com/rmagick/rmagick/pull/1930) by checking a flag that its own function sets. ---Files-------------------------------- repro.rb (707 Bytes) slow_op.c (612 Bytes) -- https://bugs.ruby-lang.org/

1 0