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

[ruby-core:126502] [Ruby Bug#22265] `Thread#value` can return before the target thread completes after a spurious Fiber scheduler unblock
by ioquatix (Samuel Williams) 20 Sep '26

20 Sep '26

Issue #22265 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22265: `Thread#value` can return before the target thread completes after a spurious Fiber scheduler unblock https://bugs.ruby-lang.org/issues/22265 * Author: ioquatix (Samuel Williams) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- Ruby 3.3 and 3.4 can allow an untimed `Thread#join` to return after a spurious Fiber scheduler wakeup, even though the target thread is still alive. Because `Thread#value` relies on `Thread#join`, it can consequently return `nil` before the thread completes. This was encountered in `io-event`, where a stale scheduler unblock could resume a fiber waiting for a worker thread. ## Reproducer ```ruby class Scheduler def initialize @root = Fiber.current @ready = [] @blocking = {} @lock = Thread::Mutex.new end def fiber(&block) fiber = Fiber.new(blocking: false, &block) fiber.transfer fiber end def block(blocker, timeout = nil) fiber = Fiber.current @blocking[fiber] = true @root.transfer ensure @blocking.delete(fiber) end def unblock(blocker, fiber) @lock.synchronize {@ready << fiber} end def kernel_sleep(duration = nil) unblock(:sleep, Fiber.current) @root.transfer true end def io_wait(io, events, duration = nil) raise NotImplementedError end def fiber_interrupt(fiber, exception) fiber.raise(exception) end def run while @blocking.any? || @ready.any? ready = @lock.synchronize do ready, @ready = @ready, [] ready end ready.each do |fiber| fiber.transfer if fiber.alive? end Thread.pass if ready.empty? end end end release = Thread::Queue.new target = Thread.new do release.pop :success end Thread.pass until target.status == "sleep" result = :unset runner = Thread.new do scheduler = Scheduler.new Fiber.set_scheduler(scheduler) joining_fiber = Fiber.schedule do result = target.value end Fiber.schedule do scheduler.unblock(:spurious_wakeup, joining_fiber) sleep(0) release << true end scheduler.run ensure Fiber.set_scheduler(nil) end runner.join target.join puts "ruby #{RUBY_VERSION}: result=#{result.inspect}" abort "Thread#value returned before completion" unless result == :success ``` ## Actual result on Ruby 3.4.4 ```text ruby 3.4.4: result=nil Thread#value returned before completion ``` Tested with: ```text ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin25] ``` ## Expected result An untimed `Thread#join` or `Thread#value` should continue waiting after a spurious wakeup: ```text ruby 3.4.4: result=:success ``` ## Existing fix This is fixed in Ruby 4.0 in PR #13532. The reproducer succeeds with Ruby 4.0.5. - Commit: `f0cf4dce65ba7bf3dc6787e10b88e08b411e2c92` - PR: https://github.com/ruby/ruby/pull/13532 ## Proposed backports Backport PRs have been prepared for both affected maintenance branches: - Ruby 3.3: https://github.com/ruby/ruby/pull/18502 - Ruby 3.4: https://github.com/ruby/ruby/pull/18503 -- https://bugs.ruby-lang.org/

2 1

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

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

7 27

[ruby-core:126530] [Ruby Bug#22273] Aliasing doesn't interact well with Module#prepend
by luke-gru (Luke Gruber) 18 Sep '26

18 Sep '26

Issue #22273 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22273: Aliasing doesn't interact well with Module#prepend https://bugs.ruby-lang.org/issues/22273 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently, aliasing doesn't interact well with `Module#prepend` in my opinion. ### Example ```ruby module Kernel prepend(Module.new do def require(feature) puts "requiring feature (prepend): #{feature}" super end end) end module Kernel alias original_require require def require(feature) puts "requiring feature (alias): #{feature}" original_require(feature) end end require "set" ``` This produces this behavior: ``` requiring feature (prepend): set requiring feature (alias): set requiring feature (prepend): set ../ruby/test.rb:5:in 'require': super: no superclass method 'require' for main (NoMethodError) ``` I would expect this behavior: ``` requiring feature (prepend): set requiring feature (alias): set # Then, the original require would succeed ``` This has caused issues such as [22263](https://bugs.ruby-lang.org/issues/22263). ### Bug? As far as I know this is intentional behavior introduced in Ruby 2.0 [here](https://bugs.ruby-lang.org/issues/7842). There are even tests and specs that codify this behavior such as `test_prepend_super_in_alias` and `prepend_spec.rb`. Even though it's intentional, I don't believe it's well thought out. I'm interested in hearing arguments for and against the current behavior (with code examples, preferably). -- https://bugs.ruby-lang.org/

6 9

[ruby-core:126537] [Ruby Bug#22276] alias in a module falls back to Object even in classes not inheriting from Object
by shugo (Shugo Maeda) 17 Sep '26

17 Sep '26

Issue #22276 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22276: alias in a module falls back to Object even in classes not inheriting from Object https://bugs.ruby-lang.org/issues/22276 * Author: shugo (Shugo Maeda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-28T07:43:16Z master 69b49ac7ae) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When `alias` (or `alias_method`) is used in a module and the method is not found in the module, `alias` searches the method from `Object`. So a module can alias a method of `Kernel` or `Object`, and the alias works even if the module is later included in a class that does not have `Object` and `Kernel` as ancestors: ```ruby module M alias foo puts public :foo end class X < BasicObject include ::M end X.new.foo("hello") #=> hello ``` `X` does not include `Kernel`, but `X.new.foo` calls `Kernel#puts`. This fallback comes from Ruby 1.8, where `Object` was the root class, so every class that includes a module always had `Object` and `Kernel` as ancestors. Since Ruby 1.9 introduced `BasicObject`, this is no longer true, but the fallback is unchanged. As discussed in #22273, a module should be able to alias only its own methods and its ancestors' methods, and `Object` is not an ancestor of a module. This behavior is intentional in the current implementation. There are tests for it (`test_alias_in_module` in test/ruby/test_alias.rb for #9663, and "accesses a method defined on Object from Kernel" in spec/ruby/core/module/alias_method_spec.rb), and the documentation of `Module#alias_method` has an example `module Mod; alias_method :orig_exit, :exit; end`. So code like `module M; alias orig_to_s to_s; end` exists, and simply raising `NameError` will break it. Possible fixes: 1. Remove the fallback and raise `NameError`. This breaks existing code. 2. Do not resolve the method at alias time. Instead, resolve it at call time from the ancestors of the receiver's class, like ZSUPER methods. Existing code that includes the module in a subclass of `Object` keeps working, and `X.new.foo` above raises `NoMethodError`. 3. Keep the current behavior and document it. I think 2 is the best choice for compatibility. -- https://bugs.ruby-lang.org/

3 5

[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:126448] [Ruby Bug#22253] Clang UBSan reports NULL/0 memcpy for eval scope locals
by yqtian (Yongqiang Tian) 15 Sep '26

15 Sep '26

Issue #22253 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22253: Clang UBSan reports NULL/0 memcpy for eval scope locals https://bugs.ruby-lang.org/issues/22253 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-20T02:56:29Z master ed0b427b4b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I found a normal Ruby eval path that passes a null source and zero length to `memcpy` in Prism. Clang's `nonnull-attribute` sanitizer reports the call because the effective glibc declaration marks the first two `memcpy` arguments as nonnull. I have not observed a crash, output corruption, or an ordinary non-sanitized failure. I am reporting this as a C correctness/toolchain-contract issue, not a security issue. #### Environment ```text x86-64 Ubuntu Clang 18.1.3 Ruby revision: ed0b427b4ba3c776c763d2673070e88372b2096a Relevant sanitizer: -fsanitize=nonnull-attribute Optimization: -O1 ``` I also checked Ruby HEAD `4012a96bf084d035bf582d58c7dafb31f4762ac6` and the corresponding Prism HEAD `3ea210b30108432b8b75b979872f4fa3c23acb7b`; the source site was unchanged. #### Reproduction I configured Ruby with Clang and the following flags: ```sh CFLAGS="-fsanitize=nonnull-attribute -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" LDFLAGS="-fsanitize=nonnull-attribute -fsanitize-recover=all" ``` Run with the instrumented Ruby: ```sh UBSAN_OPTIONS=print_stacktrace=0:halt_on_error=0:report_error_type=1 \ ./ruby -e '1.times { _1; eval("") }' ``` Clang reports: ```text prism/prism.c:23015:35: runtime error: null pointer passed as argument 2, which is declared to never be null ``` The same report occurs with `_1` through `_9`, `binding.eval`, `local_variables`, and an implicit-`it` variant. #### Cause CRuby constructs the eval scope-local array. A retained slot can have `source == NULL` and `length == 0`. `pm_parser_init` then executes: ```c const uint8_t *source = pm_string_source(local); size_t length = pm_string_length(local); uint8_t *allocated = (uint8_t *) pm_arena_alloc(&parser->metadata_arena, length, 1); memcpy(allocated, source, length); ``` A consumer-side guard removes the report: ```c if (length > 0) { memcpy(allocated, source, length); } ``` However, this crosses the CRuby/Prism integration boundary. An alternative is for CRuby to compact or initialize every retained eval-scope local before passing it to Prism. Is `{ source = NULL, length = 0 }` intended to be accepted as an empty `pm_string_t`/scope-local representation here? If so, `pm_parser_init` could handle it as a zero-length value. Otherwise, CRuby may need to guarantee a nonnull source for every retained scope-local entry. #### Validation I built unmodified and guarded trees with identical Docker/compiler/configure flags. The reproducer reports in the unmodified build and is clean in both recover and `halt_on_error=1` modes after adding the guard. The same native test set passed in both builds, including 2,065 `btest` cases, 39 eval tests with 537 assertions, and the proc and syntax tests that exercise this site. The guarded build preserved the behavior of the tested eval paths. I would be happy to prepare a patch after confirming whether the preferred invariant belongs in CRuby's eval-scope producer or Prism's consumer. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126226] [Ruby Bug#22224] YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x)
by yaroslavmarkin (Yaroslav Markin) 14 Sep '26

14 Sep '26

Issue #22224 has been reported by yaroslavmarkin (Yaroslav Markin). ---------------------------------------- Bug #22224: YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x) https://bugs.ruby-lang.org/issues/22224 * Author: yaroslavmarkin (Yaroslav Markin) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! Fair warning: a significant portion of this bugreport and experimentation/benchmarking was done by an agent. Sorry for the slop, but it was so much faster to benchmark and find a root issue. ## Summary With YJIT enabled, `vm_make_env_each` calls `rb_yjit_invalidate_ep_is_bp` on every Proc/lambda environment materialization. That function enters `with_vm_lock` unconditionally (the only early return covers boot, before `INVARIANTS` is initialized). In multi-Ractor mode this lock acquisition is `rb_jit_vm_lock_then_barrier`: the VM lock plus a stop-all-Ractors barrier. The result: any workload that creates Procs loses parallel scalability under Ractors, and beyond ~2 Ractors adding workers makes the whole process slower in absolute terms. In the repro below, 8 Ractors with YJIT run ~150x slower than 1 Ractor with YJIT, and ~195x slower than 8 Ractors without YJIT, on the same code. Note the invalidation itself is not the cost. After the first escape of a given iseq, its `no_ep_escape_iseqs` entry is an empty set forever (`ep_is_bp()` returns false for it, so no new blocks are ever registered), yet every subsequent materialization still pays lock + global barrier to look up the entry and iterate nothing. ## Standalone repro (no gems) ```ruby # Usage: ruby [--yjit] yjit_ractor_repro.rb [proc|calc] [n_ractors] [seconds] MODE = (ARGV[0] || "proc").to_sym N = (ARGV[1] || 1).to_i DUR = (ARGV[2] || 3).to_f def make_proc(i) x = i -> { x + 1 } # captures x: the frame env is materialized on every call end def work_proc(n) s = 0 n.times { |i| s += make_proc(i).call } s end def work_calc(n) s = 0 n.times { |i| s += (i * i) % 7 } # same shape, no Proc escapes s end def bench_loop(mode, dur) count = 0 deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + dur while Process.clock_gettime(Process::CLOCK_MONOTONIC) < deadline mode == :proc ? work_proc(1000) : work_calc(1000) count += 1000 end count end bench_loop(MODE, 0.5) # warm up: get the methods YJIT-compiled before measuring total = if N == 1 bench_loop(MODE, DUR) else N.times.map { Ractor.new(MODE, DUR) { |m, d| bench_loop(m, d) } }.sum(&:value) end puts format("mode=%s yjit=%s ractors=%d throughput=%.2fM iters/s", MODE, RubyVM::YJIT.enabled?, N, total / DUR / 1_000_000.0) ``` Results on Apple M1 Pro (10 cores), macOS, `ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25]`, 3 s per cell: | workload | ractors | interpreter (M iters/s) | --yjit (M iters/s) | |----------|---------|-------------------------|--------------------| | calc (control, no Proc) | 1 | 21.3 | 129.4 | | calc | 4 | 83.0 | 495.3 | | calc | 8 | 162.2 | **969.1** | | proc | 1 | 4.5 | 6.0 | | proc | 4 | 7.7 | **0.14** | | proc | 8 | 7.8 | **0.04** | The control shows this is not a general YJIT-vs-Ractor problem: on the Proc-free workload YJIT scales superbly (969M iters/s at 8 Ractors). Only the environment-materializing workload collapses, and only with YJIT on. ## Where the time goes Native sampling (macOS `sample`) of a loaded multi-Ractor process shows almost all threads parked in `__psynch_cvwait`, with the barrier initiated from: ``` vm_make_env_each -> rb_yjit_invalidate_ep_is_bp (yjit/src/invariants.rs) -> with_vm_lock -> rb_jit_vm_lock_then_barrier -> rb_ractor_sched_barrier_start (victims: rb_ractor_sched_barrier_join / ractor_sched_barrier_join_wait_locked) ``` In a 6 s sample of a 5-Ractor process, barrier-related frames appear ~9,000 times vs ~50 in the single-Ractor run of the same workload. Ruby-side profilers cannot see this: the wait time is attributed as diffuse "self time" across whatever frames are on top, which is presumably why it has gone unreported. Current code (`yjit/src/invariants.rs`, same on master as of 2026-08-03): ```rust pub extern "C" fn rb_yjit_invalidate_ep_is_bp(iseq: IseqPtr) { // Skip tracking EP escapes on boot. We don't need to invalidate anything during boot. if unsafe { INVARIANTS.is_none() } { return; } with_vm_lock(src_loc!(), || { let no_ep_escape_iseqs = &mut Invariants::get_instance().no_ep_escape_iseqs; match no_ep_escape_iseqs.get_mut(&iseq) { Some(blocks) => { for block in mem::take(blocks) { invalidate_block_version(&block); incr_counter!(invalidate_ep_escape); } } None => { no_ep_escape_iseqs.insert(iseq, HashSet::new()); } } }); } ``` ## Real-world impact Rails 8.1 enables YJIT by default, and a Rails request materializes many Proc environments (middleware blocks, route handling, view rendering), so any Rails app served by a multi-Ractor server hits this out of the box. Found while investigating https://github.com/yaroslav/kino/issues/6, where a stock Rails 8.1 app showed worker scaling inverting: more Ractors, less total throughput. Rails 8.1.3 health-check endpoint (`/up`, no database), `ab -c 64 -k`, kino `:ractor` mode, N workers x 1 thread, requests/sec: | workers | YJIT on (Rails default) | YJIT off | |---------|-------------------------|----------| | 1 | 6,416 | 3,964 | | 2 | 5,036 | 6,999 | | 5 | 2,800 | 13,269 | | 8 | 2,003 | 12,596 | Fully disabling GC changed the YJIT-on numbers by only ~7%, ruling out GC barriers as the driver; the native profile above identifies the initiator. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126087] [Ruby Bug#22196] Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10
by scohen-tines (seth cohen) 14 Sep '26

14 Sep '26

Issue #22196 has been reported by scohen-tines (seth cohen). ---------------------------------------- Bug #22196: Heap-use-after-free in `fiber_switch` with transfer-terminated async tasks on 3.4.10 https://bugs.ruby-lang.org/issues/22196 * Author: scohen-tines (seth cohen) * Status: Open * ruby -v: ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Heap-use-after-free in `fiber_switch` reading terminated fiber's status (regression via Bug #21955 backport) Ruby 3.4.10 intermittently segfaults while an async-http workload terminates task fibers after truncated chunked HTTP responses. The equivalent workload completed 20 high-churn attempts on Ruby 3.4.9 without a crash. ASan shows a heap-use-after-free: the outgoing fiber's `rb_fiber_t` is freed by GC while `fiber_switch` still reads its status on the `Fiber#transfer` path. ## Environment ```text ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [aarch64-linux] ``` - Linux `aarch64` Docker image. - `async-1.32.1`, `async-http-0.64.2`, and `async-pool-0.10.3`. - The ASan build uses `-fsanitize=address -fno-omit-frame-pointer -g -O0` and has YJIT disabled. ## Expected behavior An incomplete chunked HTTP response should fail its async task with `EOFError`; the VM should not crash while cleaning up the task fiber. ## Actual behavior Ruby exits with a segmentation fault in the fiber stack pool: ```text -- C level backtrace -- fiber_pool_stack_release fiber_stack_release fiber_switch rb_fiber_start ``` One GDB run on a source-built 3.4.10 reached: ```text #0 fiber_pool_stack_release (stack=0xffffc4012ea0) at cont.c:770 pool = 0x0 #1 fiber_stack_release (fiber=0xffffc4012b00) at cont.c:903 #2 fiber_switch (...) at cont.c:2728 ``` We first hit this in a production service; the harness below reproduces the same C-level frames using only async-http against a local server, with no application code. ## AddressSanitizer result An ASan build makes the bug deterministic. With 50 in-process request bursts, all five stock 3.4.10 runs report: ```text ERROR: AddressSanitizer: heap-use-after-free READ of size 1 #0 fiber_switch /src/ruby-3.4.10/cont.c:2727 ... freed by thread T2 here: cont_free /src/ruby-3.4.10/cont.c:1079 fiber_free /src/ruby-3.4.10/cont.c:1164 ... previously allocated by thread T3 here: fiber_t_alloc /src/ruby-3.4.10/cont.c:1986 SUMMARY: AddressSanitizer: heap-use-after-free /src/ruby-3.4.10/cont.c:2727 in fiber_switch ``` Line 2727 of `cont.c` is the new `FIBER_TERMINATED_P(fiber)` condition (see Regression candidate below). Thus the first invalid operation is reading the freed `rb_fiber_t` object's status. It occurs before `fiber_pool_stack_release`; the latter is a downstream manifestation when the stale status reads as terminated and the release branch continues. The full report is attached as `stock-1.log`. ## Minimal reproduction harness The attached harness consists of: - `repro.rb`: local raw HTTP server plus direct async-http client; - `Gemfile` and `Gemfile.lock`: pinned async dependencies; - `Dockerfile` and `run.sh`: repeat the workload on a stock Ruby image. Run: ```sh ./run.sh 3.4.10 20 ``` This is probabilistic; successful runs are expected. The harness retains a log for every attempt and reports the first interpreter crash. The workload synchronizes groups of ten failures by default: ```sh FAULT_BARRIER=10 ./run.sh 3.4.10 50 ``` Run the same source comparison under ASan (deterministic): ```sh BATCHES=50 ./run-asan.sh 5 ``` `./run.sh 3.4.9 20` completes all 20 attempts without a crash; 3.4.9 predates the `148f263a` backport. ## Regression candidate Ruby 3.4.10 includes ruby_3_4 commit [`148f263a`](https://github.com/ruby/ruby/commit/148f263a0d299e4532c753470a282144c9104820), the backport of [`dc1777d`](https://github.com/ruby/ruby/commit/dc1777d01770ab62ec99ff6fa4cf622098f44968) for [Bug #21955](https://bugs.ruby-lang.org/issues/21955). That changes `fiber_switch` as follows: ```diff - if (resuming_fiber && FIBER_TERMINATED_P(fiber)) { + if (FIBER_TERMINATED_P(fiber)) { fiber_stack_release(fiber); } ``` `Fiber#transfer` passes a null `resuming_fiber`, so the old condition short-circuited without reading `fiber->status`. The new condition dereferences the stale `fiber` pointer before deciding whether to release its stack. We have not tested ruby-head/3.5, but the same condition is present there since `dc1777d`, so we expect it to be affected. ## Controlled source comparison The harness also includes: ```sh BATCHES=20 ./run-ab.sh 20 ``` It builds the published Ruby 3.4.10 source twice with the same compiler and workload: 1. stock 3.4.10; 2. 3.4.10 with only the above condition restored to `resuming_fiber && FIBER_TERMINATED_P(fiber)`. | Build | Attempts | `fiber_pool_stack_release` crashes | | --- | ---: | ---: | | stock 3.4.10 | 20 | 4 | | 3.4.10 with Bug #21955 condition reverted | 20 | 0 | The stock run also had one additional process abort with: ```text malloc(): unaligned tcache chunk detected ``` All 20 reverted-build processes completed successfully. These runs used `BATCHES=20`, 100 requests per batch, concurrency 20, and a barrier of 10 simultaneous truncated responses. The image is built from the Ruby 3.4.10 release tarball with `-O0 -g3 -fno-omit-frame-pointer`; the only source difference between the two images is the condition shown above. The ASan A/B uses `BATCHES=50`: all 5 stock runs report the above heap-use-after-free, while all 5 reverted runs complete cleanly. ## Request Could the fiber maintainers review why a `rb_fiber_t` can be finalized by GC while `fiber_switch` still holds it as the outgoing fiber? Reinstating the `resuming_fiber` guard avoids the dereference on the transfer path, but a proper fix likely needs to ensure that the outgoing fiber remains live through the switch or otherwise avoid reading it after its lifetime ends. ---Files-------------------------------- ruby-3.4.10-fiber-uaf.tar.gz (19.7 KB) stock-1.log (58.4 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:126379] [Ruby Feature#22243] Change fork behavior when Process._fork raises an exception during fork with a block argument
by rpeng (Richard Peng) 14 Sep '26

14 Sep '26

Issue #22243 has been reported by rpeng (Richard Peng). ---------------------------------------- Feature #22243: Change fork behavior when Process._fork raises an exception during fork with a block argument https://bugs.ruby-lang.org/issues/22243 * Author: rpeng (Richard Peng) * Status: Open ---------------------------------------- # Problem Ruby exposes Process.fork in two formats - one with block arguments and one without. When a block is passed in, the implicit contract is that a child process will terminate once the block ends. However, it is possible for the child to "escape" the enclosed block in certain circumstances when Process._fork raises an exception. Here's a demonstration of what may occur: ```ruby module BadForkTracker def _fork pid = super if pid == 0 raise "exception during fork in child" # end pid end end Process.singleton_class.prepend(BadForkTracker) loop do sleep(1) puts "I'm parent #{Process.pid}" fork do puts "I'm child #{Process.pid} and I'm exiting" end rescue StandardError => e puts "#{Process.pid} Received Error: #{e}" # <- child ends up in this block, then resumes the loop. most users will not be expecting this. end ``` In practice, there are many libraries that implement "fork tracking" (active_support, datadog, connection_pool, to name a few) by prepending to the `Process` module. Many of which are designed to run user specified callbacks which increases the surface area of errors occurring. This means that on _fork, there's a good chance that something will throw and cause a child to resume execution in the "parent" context. In addition, many workloads (sidekiq, puma) have global rescues that are similar to the example case I provided above, which would unintentionally cause the child to continue execution. # Proposal I am proposing a change in behavior: when Process.fork is called with a block, if Process._fork raises an exception in the child, immediately terminate the child with an error exit code (instead of relying on an enclosing rescue to handle it). This guarantees that a child cannot escape out of the block it was meant to execute. In my opinion, this is more in line with how libraries generally expect this to work (e.g. there are very few libraries that are being defensive and attempting not to throw in `def _fork` overrides). -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126222] [Ruby Bug#22223] Socket.tcp with connect_timeout returns a phantom "connected" socket for a refused connection on macOS 27 (kernel answers EISCONN on connect retry; SO_ERROR never consulted)
by tdehnke (Tony Dehnke) 14 Sep '26

14 Sep '26

Issue #22223 has been reported by tdehnke (Tony Dehnke). ---------------------------------------- Bug #22223: Socket.tcp with connect_timeout returns a phantom "connected" socket for a refused connection on macOS 27 (kernel answers EISCONN on connect retry; SO_ERROR never consulted) https://bugs.ruby-lang.org/issues/22223 * Author: tdehnke (Tony Dehnke) * Status: Open * ruby -v: ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary On macOS 27.0 (beta, build 26A5388g, arm64 — M5), `Socket.tcp(host, port, connect_timeout: X)` returns a socket object instead of raising `Errno::ECONNREFUSED` when nothing is listening on the port. The returned socket is not usable (first `write` raises `Errno::EPIPE`). The blocking paths (`connect_timeout: nil`, `TCPSocket.new`) raise `Errno::ECONNREFUSED` correctly. ⚠️ Note: this is a macOS **beta** build; the kernel behavior may change before release. Reporting anyway because Ruby's connect idiom is not robust against it, and the failure is silent (phantom success, not an error). ## Repro (no listener on port 3999) ```ruby require "socket" Socket.tcp("127.0.0.1", 3999, connect_timeout: 1) # => #<Socket ...> (expected: Errno::ECONNREFUSED) Socket.tcp("127.0.0.1", 3999, connect_timeout: 1, fast_fallback: false) # => #<Socket ...> (same — not Happy-Eyeballs-specific) Socket.tcp("127.0.0.1", 3999, connect_timeout: nil) # blocking path # => Errno::ECONNREFUSED (correct) TCPSocket.new("127.0.0.1", 3999) # => Errno::ECONNREFUSED (correct) s = Socket.tcp("127.0.0.1", 3999, connect_timeout: 1) s.write("x") # => Errno::EPIPE — the "connected" socket was never connected ``` Reproduced identically on ruby 3.4.5 (arm64-darwin27) and ruby 3.4.10 (arm64-darwin27). Other tools on the same machine (curl, a blocking C connect) report Connection refused correctly and instantly. ## Root cause observed The classic nonblocking idiom — `connect_nonblock` → wait writable → retry `connect_nonblock`, treating `Errno::EISCONN` as success (as recommended in Ruby's own `connect_nonblock` documentation, and as used by `Socket.tcp`'s connect_timeout path) — is broken by a Darwin 27 kernel behavior change. C-level demonstration on a refused nonblocking connect: ``` first connect: r=-1 errno=36 (Operation now in progress) poll: r=1 revents=0x10 # POLLHUP — yet the fd is reported "ready" retry connect: r=-1 errno=56 (Socket is already connected) # EISCONN, on a REFUSED socket SO_ERROR: 61 (Connection refused) # the truth is still available here ``` So the kernel answers the retry-`connect(2)` with `EISCONN` instead of `ECONNREFUSED`, and Ruby's idiom takes that as "connected". `getsockopt(SO_ERROR)` still reports `ECONNREFUSED` — checking it after writability (before/instead of trusting the connect-retry result) detects the failure correctly. Ruby-level equivalent: ```ruby sock = Socket.new(:INET, :STREAM) addr = Socket.sockaddr_in(3999, "127.0.0.1") begin sock.connect_nonblock(addr) rescue IO::WaitWritable sock.wait_writable(2) # returns "writable" begin sock.connect_nonblock(addr) # raises Errno::EISCONN (!) rescue Errno::EISCONN sock.getsockopt(Socket::SOL_SOCKET, Socket::SO_ERROR).int # => 61 ECONNREFUSED end end ``` ## Impact Any code probing "is something listening?" via `Socket.tcp` with a `connect_timeout` silently gets a false positive on this platform. Found in the wild: shakapacker's `Shakapacker::DevServer#running?` (probe with `connect_timeout: 0.1`) reported a webpack dev server that wasn't there, so its Rails middleware proxied every asset request into a dead port — every page 502s with no error pointing anywhere near the cause. ## Suggested direction After waiting for writability in the connect_timeout / HEv2 paths (and possibly in the documented `connect_nonblock` idiom), consult `getsockopt(SO_ERROR)` rather than relying on the retry-`connect` returning `EISCONN` — SO_ERROR carries the correct `ECONNREFUSED` even when the kernel misanswers the retry. (Also plausibly worth an Apple Feedback report; the poll `revents=POLLHUP`-as-ready + `EISCONN`-on-refused combination looks like an OS regression.) ## Environment - macOS 27.0 (beta), build 26A5388g, Apple Silicon (M5), Darwin 27 - ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin27] — also ruby 3.4.10 [arm64-darwin27] - Possibly related (different symptom, same neighborhood): Bug #21104 (Net::HTTP failures on macOS ≥ 3.4, hardware-dependent, RUBY_TCP_NO_FAST_FALLBACK workaround). Unlike #21104, this repro is NOT affected by `fast_fallback: false`. -- https://bugs.ruby-lang.org/

4 4