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

[ruby-core:126154] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by hsbt (Hiroshi SHIBATA) 24 Jul '26

24 Jul '26

Issue #11438 has been updated by hsbt (Hiroshi SHIBATA). https://github.com/ruby/ruby/pull/18054 ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-118198 * Author: rickerliang (l ly) * Status: Assigned * Assignee: windows * ruby -v: 2.2.2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126138] [Ruby Misc#22206] Replace `tool/update-deps` with source-based dependency generation
by nobu (Nobuyoshi Nakada) 24 Jul '26

24 Jul '26

Issue #22206 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #22206: Replace `tool/update-deps` with source-based dependency generation https://bugs.ruby-lang.org/issues/22206 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose replacing `tool/update-deps` with `tool/mkdepend.rb`, a dependency generator written in Ruby that scans the source files directly. The complete dependency lists would be generated into the build directory instead of being committed. The repository would retain only the source mappings and manual rules needed to determine which source builds each object. ## Problems with `tool/update-deps` `tool/update-deps` has several practical problems. 1. It depends on GNU make and GCC-specific output. It obtains build information from `make -p` and requires GCC’s `-save-temps=obj` option. This also means that `ccache` and similar compiler wrappers must be disabled. The dependency update procedure therefore cannot run directly on every platform supported by Ruby. 2. Updating dependencies is expensive. The current procedure requires a configured tree and a compiler build before dependencies can be inspected. A dependency-only change should not require compiling Ruby and its extensions first. 3. The generated `depend` files are very large. Most of their contents are mechanically generated header dependencies. They make reviews noisy, cause large diffs when a commonly included header changes, and are easy to leave stale. In the prototype, approximately 70,000 generated lines can be removed from 98 `depend` files. 4. The checked-in files duplicate information available from the sources. Most header dependencies can be obtained by recursively following `#include` directives. Only the object-to-source mappings and a small number of rules for generated or substituted sources need to be recorded explicitly. ## Proposal Add `tool/mkdepend.rb` and use it instead of `tool/update-deps`. `tool/mkdepend.rb` scans C and parser sources recursively, resolves quoted and angle-bracket includes using Ruby’s source layout, and writes Make dependency rules. It does not require a configured build, GNU make, or a C compiler, and it runs with Ruby 3.1. Unknown preprocessor conditions are handled conservatively by scanning both branches. Source-specific `define` and `undef` declarations are available when one branch must be selected. Small declarations in `depend` files also describe generated source templates, logical dependencies, and macro-based include names that cannot be inferred from ordinary file lookup. Targets declared in the manual part of each `depend` file are treated as generated files. This avoids maintaining a second list of generated files. ### Repository and build directory layout The sections between these markers remain in the repository: ```make # AUTOGENERATED DEPENDENCIES START array.$(OBJEXT): {$(VPATH)}array.c # AUTOGENERATED DEPENDENCIES END ``` They contain only the minimal object-to-source mappings. Manual Make rules outside the section remain unchanged. When a base Ruby is available, `configure` expands these mappings and writes the complete dependency files under `.deps` in the build directory. The generated Makefile includes those files. This applies to out-of-tree builds, GNU make builds, and Windows NMAKE builds. Release snapshots expand the dependencies before packaging. A release tarball can therefore still be configured without a base Ruby and use the dependency files included in the source tree. ### Commands The proposed commands are: ```sh # Check the committed source mappings. ruby tool/mkdepend.rb --scope=all --sources --check # Update the committed source mappings. ruby tool/mkdepend.rb --scope=all --sources --inplace # Generate complete dependencies. ruby tool/mkdepend.rb --scope=all --output=.deps ``` The existing `make check-depends` and `make fix-depends` targets invoke these operations, so contributors do not need to remember the command-line details. ## Benefits - Dependency generation works without GNU make or GCC. - It runs before the main build and does not require compiler output. - Complete dependencies are generated for the current source tree on every build instead of being kept as a large generated snapshot in Git. - Dependency updates become small and reviewable, usually changing only an object-to-source mapping or an explicit declaration. - The same generator can produce paths appropriate for GNU make and NMAKE. - Out-of-tree builds keep generated dependency data out of the source tree. ## Limitations This is a dependency scanner, not a complete C preprocessor. Conditions that cannot be decided safely are scanned in both directions, which may produce extra dependencies but should not omit required ones. The scanner also cannot infer that a newly added C file should become a build object when there is no object rule for it. That information belongs to the Makefile or the minimal source mapping and must still be added explicitly. ## Prototype A working implementation is available at: <https://github.com/nobu/ruby/tree/mkdepend> It includes the source scanner, dependency declarations, configure and NMAKE integration, snapshot handling, dependency checks, and tests for Ruby 3.1. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126149] [Ruby Bug#22209] IO#set_encoding is ignoring the :newline keyword argument when given Encoding positional argument
by andrykonchin (Andrew Konchin) 23 Jul '26

23 Jul '26

Issue #22209 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #22209: IO#set_encoding is ignoring the :newline keyword argument when given Encoding positional argument https://bugs.ruby-lang.org/issues/22209 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### Behavioral Discrepancy of the `:newline` Option with Single `Encoding` Objects When calling `IO#set_encoding` with a single positional argument, the `:newline` option (e.g., `newline: :universal`) is parsed and applied only when the encoding is passed as a `String`. When passed as an `Encoding` object, the option is silently ignored and no validation or conversion is performed. #### 1. Passing Encoding as a String (option applied correctly) When the encoding is specified as a `String`, the `:newline` option is parsed and correctly normalizes CRLF line endings to LF: ```ruby data = "line1\r\nline2\r\n" File.write("1.txt", data) File.open("1.txt") do |f| f.set_encoding("utf-8", newline: :universal) p f.read # => "line1\nline2\n" end ``` #### 2. Passing Encoding as an Encoding Object (option ignored) When the encoding is specified as an Encoding object, the `:newline` option is ignored, and the CRLF line endings remain unmodified: ```ruby data = "line1\r\nline2\r\n" File.write("1.txt", data) File.open("1.txt") do |f| f.set_encoding(Encoding::UTF_8, newline: :universal) p f.read # => "line1\r\nline2\r\n" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126146] [Ruby Bug#22208] Install compile seg fault ruby-3.2.4 on openSuSE Leap 16
by wmotycka (Wayne Motycka) 23 Jul '26

23 Jul '26

Issue #22208 has been reported by wmotycka (Wayne Motycka). ---------------------------------------- Bug #22208: Install compile seg fault ruby-3.2.4 on openSuSE Leap 16 https://bugs.ruby-lang.org/issues/22208 * Author: wmotycka (Wayne Motycka) * Status: Open * ruby -v: 3.2.4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Platform: NAME="openSUSE Leap" VERSION="16.0" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="16.0" PRETTY_NAME="openSUSE Leap 16.0" RVM version: rvm 1.29.12 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io] I'm using RVM to install ruby-3.2.4 on this system. A seg fault during the compilation of tools/transform_mjit_header.rb with the indicted line number is doing a string gsub! operation. I ran RVM --trace to garner the attached rvm_3.2.4_install_trace.out. Also tried installing ruby-3.2.9 through RVM and same result (seg fault) from the same tools/transform_mjit_header.rb script. ---Files-------------------------------- rvm_install_324_make.log (91.7 KB) rvm_3.2.4_install_trace.out (736 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126140] [Ruby Misc#22207] Sorting issues in Redmine not allowed when logged out
by p8 (Petrik de Heus) 23 Jul '26

23 Jul '26

Issue #22207 has been reported by p8 (Petrik de Heus). ---------------------------------------- Misc #22207: Sorting issues in Redmine not allowed when logged out https://bugs.ruby-lang.org/issues/22207 * Author: p8 (Petrik de Heus) * Status: Open ---------------------------------------- When I'm logged out sorting on the updated_on isn't allowed. The following page results in a 403: https://bugs.ruby-lang.org/projects/ruby-master/issues?sort=updated_on%3Ade… This doesn't happen on the official Redmine website: https://www.redmine.org/projects/redmine/issues?sort=updated_on%3Adesc%2Cid… -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125938] [Ruby Feature#22182] Optimize method chains by destructively updating intermediate objects
by mame (Yusuke Endoh) 20 Jul '26

20 Jul '26

Issue #22182 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #22182: Optimize method chains by destructively updating intermediate objects https://bugs.ruby-lang.org/issues/22182 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- This is an experimental optimization idea that speeds up typical method chains by destructively updating their intermediate objects. Intuitively, it works like this: * `str.strip.upcase` runs like `str.strip.upcase!` * `ary.map {}.select {}` runs like `ary.map {}.select! {}` * `"foo" + str + str` runs like `"foo" << str << str` As a bonus: * `foo(**opts.merge(default))` passes the merged hash to the callee as-is, without `Hash#dup` ## Microbenchmarks 1-second measurement windows, average of 5 alternating rounds (µs/call). |Code|Before|After|Speedup|Setup| |--|--|--|--|--| |`str + str + str`| 0.127 µs | 0.088 µs | 1.44x |`str = "x" * 100`| |`ary + ary + ary`| 0.645 µs | 0.304 µs | 2.12x |`ary = (0..99).to_a`| |`"foo" + str`| 0.083 µs | 0.056 µs | 1.50x |`str = "bar"`| |`ary.map { it+1 }.select { it.even? }`| 6.86 µs | 6.64 µs | 1.03x |`ary = (0..99).to_a`| |`str.strip.upcase`| 0.099 µs | 0.090 µs | 1.10x |`str = " foo "`| |`"#{a}#{b}".strip`| 0.110 µs | 0.103 µs | 1.07x |`a = "abcdefgh"; b = "ijklmnop"`| |`ary.uniq.sort.reverse`| 38.7 µs | 36.4 µs | 1.06x |`ary = (0..999).map { it % 500 }.shuffle`| |`foo(**opts.merge(default))`| 0.557 µs | 0.489 µs | 1.14x |`def foo(**kw) = kw; opts = (0...10).to_h { [:"o#{it}", it] }; default = (0...10).to_h { [:"d#{it}", it] }`| Allocations go down as well (e.g. `str + str + str` goes from 2 objects to 1). ## How it works In one sentence: a limited form of escape analysis, specialized for method chains. We introduce flags (`STR_FRESH` / `ARY_FRESH` / `HASH_FRESH`) for `String` / `Array` / `Hash` objects whose only reference is guaranteed to be a single value-stack slot. Since no one else can observe a flagged object, the next operation may reuse it destructively. A few instructions are added. The typical one is `opt_plus_fresh`. For example, `str1 + str2 + str3` compiles and runs as: ``` getlocal str1 getlocal str2 opt_plus_fresh # concatenate into a new String and set STR_FRESH on it; since it will # almost certainly be appended to, allocate with extra (2x) capacity getlocal str3 opt_plus # if the receiver has STR_FRESH, append in place instead of # allocating a new object ``` `ary.map {}.select {}` compiles and runs as: ``` getlocal ary send :map (callinfo: VM_CALL_FRESH_PROD) # if the method cache resolved to the built-in # Array#map, set ARY_FRESH on the resulting array send :select (callinfo: VM_CALL_FRESH_CONS) # if the method cache resolved to the built-in # Array#select and the receiver has ARY_FRESH, # call the select!-style destructive implementation ``` There are also a few instructions that create objects with the FRESH flag set (`newarray_fresh`, `duparray_fresh`, `dupstring_fresh`, `concatstrings_fresh`). These make `"foo" + str`, `[1, 2, 3].sort` and `"#{a}#{b}".strip` destructive as well. ## PoC implementation Implemented by Claude Code (Fable 5). Still a proof of concept. https://github.com/ruby/ruby/pull/17685 9 commits: 1. Add the STR_FRESH / ARY_FRESH / HASH_FRESH object flags (+ clearing in ObjectSpace.each_object) 2. Preparatory refactoring: extract str_enc_buf_new0() from str_enc_new() 3. String#+ chains: reuse the intermediate in place (opt_plus_fresh / dupstring_fresh) 4. Array#+ chains: same 5. Built-in String chains: apply destructive counterparts to fresh receivers (strip.downcase, sub with arguments, interpolated heads, ...) — also introduces the common machinery (unconditional callinfo bits + fresh_producer/fresh_consumer method entry bits + the table) 6. Built-in Array chains (map/select/... + take/drop + split/to_a/flat_map/sort_by/set-operation producers + literal heads like `[3,1,2].sort`) 7. Built-in Hash chains (merge/transform_values/select/reject/compact) 8. Hand over fresh splat / kw-splat operands (`f(*xs.map {})` / `foo(**opts.merge(default))` skip the defensive copy — a runtime generalization of the existing `VM_CALL_ARGS_SPLAT_MUT` / `KW_SPLAT_MUT`) 9. Minimal YJIT support (+ chains are also fused in JITed code; built-in send chains stay inactive but sound. Same for ZJIT.) ## Implementation notes This optimization needs delicate care so that FRESH-flagged objects never leak into ordinary code. Optimization is therefore applied only in very restricted situations: * Only chains that use known method names (`map`, `select`, ...) are optimized. (This prevents a leak through e.g. `ary.map {}.tap { it }`.) * Optimization applies only while none of those `String`/`Array`/`Hash` methods are redefined. * `ObjectSpace.each_object` clears the FRESH flag of every object it yields. * A receiver passed to `method_missing` has its FRESH flag cleared. * In case a target method is redefined in the middle of a chain, a consumer site whose call cache was invalidated clears the receiver's FRESH flag. There may be other paths through which a FRESH object can leak; please let me know if you spot one. In principle this should almost never slow down ordinary code: the only cost is one FRESH flag test in `opt_plus` for String and Array. Indeed, a plain `str + str` (not optimized) measured 0.071 µs both before and after the patch (1.00x). Fixnum `+`, standalone `merge` / `sort`, `foo(**h)` etc. all measured 0.98-1.03x. ## Limitations String has no spare flag bits, so the PoC reuses STR_PRECOMPUTED_HASH == STR_FRESH: the bit is read as STR_PRECOMPUTED_HASH on frozen strings and as STR_FRESH on unfrozen ones. Under `frozen-string-literal: true`, `"foo" + str` is currently not optimized (perhaps improvable?). YJIT support is provisional. `+` chains are fused in JITed code too, but the destructive reuse in built-in send chains only happens in interpreted execution. In particular, with a JIT enabled, Array chains are disabled entirely (YJIT redefines `Array#map` / `Array#select` in Ruby, which trips the redefinition detection, unfortunate). Only prism is supported for now (parse.y is not). There are probably other things I have missed. ## Discussion Ordinary code does not get slower, and some code skips intermediate allocations entirely, so I believe this is essentially all upside. That said, keeping FRESH objects from leaking makes this a fairly intricate and delicate optimization, so I would like to hear from VM and JIT developers. Whether this shows up in "macro" benchmarks is questionable: code like `"foo" + str + str + str`, where the optimization shines, has traditionally been avoided, and the intermediate objects it eliminates would almost certainly have been collected by minor GC anyway, so they rarely amount to real GC pressure. Still, having common idioms like `"foo" + str` or `ary.uniq.sort.reverse` get 1.1-1.5x faster is a nice thing, and reducing the general uneasiness about "this creates an intermediate array" seems worthwhile, IMO. What do you think? -- https://bugs.ruby-lang.org/

4 15

[ruby-core:126077] [Ruby Bug#22194] File.realpath and File.realdirpath handle differently path encoding incompatible to a filesystem's one
by andrykonchin (Andrew Konchin) 20 Jul '26

20 Jul '26

Issue #22194 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #22194: File.realpath and File.realdirpath handle differently path encoding incompatible to a filesystem's one https://bugs.ruby-lang.org/issues/22194 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Both `realpath` and `realdirpath` methods accept a `path` parameter and try to return result in the `path`'s encoding. `realpath`: ```ruby File.realpath(".rubocop.yml").encoding # => #<Encoding:UTF-8> File.realpath(".rubocop.yml".encode("US-ASCII")).encoding # => #<Encoding:US-ASCII> ``` `realdirpath`: ```ruby File.realdirpath("src").encoding # => #<Encoding:UTF-8> File.realdirpath("src".encode("US-ASCII")).encoding # => #<Encoding:US-ASCII> ``` But it's possible that `path`'s encoding isn't compatible to the filesystem's one (that's is common to be UTF-8 on Linux and macOS), that's converting from the filesystem's encoding to `path`'s encoding fails. In this case `realpath` and `realdirpath` behaves differently - `realpath` just "forces" encoding to `path`'s one (and as fallback to filesystem's and then to binary if a string becomes broken) and `realdirpath` just returns a string in the filesystem's encoding. `realpath`: ```ruby File.realpath(".".encode(Encoding::ISO_8859_1), "test_dir_🦊").encoding # => #<Encoding:ISO-8859-1> ``` `realdirpath`: ```ruby File.realdirpath(".".encode(Encoding::ISO_8859_1), "test_dir_🦊").encoding # => #<Encoding:UTF-8> ``` It makes sense for the methods to handle this edge case consistently. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115018] [Ruby master Bug#19922] ObjectSpace.dump_all in multiple threads in parallel causes SEGV
by wanabe (_ wanabe) 20 Jul '26

20 Jul '26

Issue #19922 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #19922: ObjectSpace.dump_all in multiple threads in parallel causes SEGV https://bugs.ruby-lang.org/issues/19922 * Author: wanabe (_ wanabe) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `ObjectSpace.dump_all` in multiple threads in parallel causes SEGV. The reproduce code is here: ``` $ ruby -robjspace -e 'def dump; 10.times { ObjectSpace.dump_all } end; Thread.new { dump }; dump' /home/wanabe/.rbenv/versions/master/lib/ruby/3.3.0+0/objspace.rb:100: [BUG] Segmentation fault at 0x0000000000000000 (snip) ``` I attached the full log. I assumed that: - Thread1 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd1 - calls `dump_flush()` - changes current thread due to IO - Thread2 - calls `rb_objspace_reachable_objects_from_root()` - changes `GET_RACTOR()->mfd`: mfd2 - calls `dump_flush()` - changes current thread due to IO - Thread1 - gets unexpected `GET_RACTOR()->mfd`: mfd2 ---Files-------------------------------- bug.log (23.1 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:126115] [Ruby Bug#22203] Coverage (eval: true): branch entries for re-eval'd code are nondeterministically duplicated
by sferik (Erik Berlin) 20 Jul '26

20 Jul '26

Issue #22203 has been reported by sferik (Erik Berlin). ---------------------------------------- Bug #22203: Coverage (eval: true): branch entries for re-eval'd code are nondeterministically duplicated https://bugs.ruby-lang.org/issues/22203 * Author: sferik (Erik Berlin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When the same code is eval'd more than once against the same file path under `Coverage.start(branches: true, eval: true)`, the branch section of `Coverage.result` sometimes contains one condition entry with accumulated arm counts, and sometimes contains multiple condition entries at identical source coordinates (differing only in their id element), each carrying only the executions of one compile. Which of the two shapes you get varies from run to run of the same program and is influenced by GC. On Ruby 3.2 through 3.4 the entries were almost always merged. On Ruby 4.0 they are almost always duplicated, so programs that rely on the long-standing de facto behavior changed silently. This is related to but distinct from #19857, which asked for line counts to accumulate across evals and was rejected as a design decision. My concern is that the shape of the branch result is nondeterministic and that lines and branches disagree with each other in a single run. #### Reproduction ```ruby require "coverage" Coverage.start(lines: true, branches: true, eval: true) src = "if $flag\n :a\nelse\n :b\nend\n" $flag = true; eval(src, binding, "fake.rb", 1) $flag = false; eval(src, binding, "fake.rb", 1) result = Coverage.result["fake.rb"] puts "conditions: #{result[:branches].size}" result[:branches].each { |cond, arms| puts " #{cond.inspect} => #{arms.values.inspect}" } puts "lines: #{result[:lines].inspect}" ``` Adding `GC.start` between the two evals makes the duplication reproduce on every run on 4.0.6. I'd expect that either the second compile reuses the existing branch entries for that path, so there is one condition whose arm counts cover both evals (the behavior Ruby 3.2 through 3.4 exhibit) or every compile appends fresh entries, always. I can work with either semantics, but can’t rely on a structure that depends on GC timing. In the current state, SimpleCov and similar tools can’t distinguish one branch, observed twice from two branches, each half-observed. Here are examples of the two different shapes I'm seeing across runs of identical code: Merged (one condition, arms accumulated across both evals): ``` conditions: 1 [:if, 0, 1, 0, 5, 3] => [1, 1] ``` Duplicated (two conditions at identical coordinates, complementary counts): ``` conditions: 2 [:if, 0, 1, 0, 5, 3] => [1, 0] [:if, 3, 1, 0, 5, 3] => [0, 1] ``` Observed rates for 10 runs each, "gc" meaning `GC.start` inserted between the two evals: ``` ruby 3.2.11: plain 0/10 duplicated, gc 1/10 duplicated ruby 3.3.12: plain 0/10 duplicated, gc 0/10 duplicated ruby 3.4.10: plain 0/10 duplicated, gc 1/10 duplicated ruby 4.0.6: plain 9/10 duplicated, gc 10/10 duplicated ``` So the failure to reuse existing entries has existed at low frequency since eval coverage was introduced (it can be provoked with GC pressure on 3.2 through 3.4), and Ruby 4.0 inverted the common case. Additionally, lines and branches disagree within a single run. Eval'ing the same code twice down the same arm gives: ``` lines: [1, 1, nil, 0, nil] # line counts reflect only the last compile (per #19857 design) branches: [:then] => 2 # branch counts accumulated across both compiles ``` The branch counter says the arm ran twice while line coverage says its line ran once. Whichever semantics is intended, the two criteria should agree. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125892] [Ruby Feature#22138] Add `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag for `rb_nogvl`.
by ioquatix (Samuel Williams) 20 Jul '26

20 Jul '26

Issue #22138 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22138: Add `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag for `rb_nogvl`. https://bugs.ruby-lang.org/issues/22138 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- Add a new flag, `RB_NOGVL_PENDING_INTERRUPT_FAIL`, to `rb_nogvl()`. When set, `rb_nogvl()` does not enter the blocking region (does not call the supplied function) if the current thread has *pending interrupts* — including interrupts that are currently masked by `Thread.handle_interrupt`. In that case it returns `0` without calling the function, with `errno == 0` — the same as the existing `RB_NOGVL_INTR_FAIL` skip path (the function was never called). This gives selector / event-loop extensions a reliable way to detect that a thread has work to do (a pending interrupt) *before* committing to a potentially unbounded native wait, so they can unwind and let Ruby process the interrupt instead of hanging. ## Background and motivation `rb_nogvl()` already supports a "fail before blocking" mode via `RB_NOGVL_INTR_FAIL` (`0x1`). With that flag, if the VM has been interrupted (`RUBY_VM_INTERRUPTED_ANY`) before the blocking region is entered, the function is skipped and `rb_nogvl()` returns `0`. This is used by `rb_thread_call_without_gvl2()`. However, `RB_NOGVL_INTR_FAIL` only reacts to *deliverable* interrupts. It does not account for interrupts that the current thread has deliberately deferred via `Thread.handle_interrupt`. There is an important class of bugs where: 1. A thread has a pending interrupt (e.g. a `Thread#raise`, a timeout, a shutdown/termination request). 2. That interrupt is masked by an enclosing `Thread.handle_interrupt(... => :never)` / `:on_blocking` region — typical in schedulers, supervisors and connection pools that want to control exactly where interrupts are delivered. 3. The thread is about to enter a native wait (e.g. `kqueue`/`epoll`/`select`, or some other blocking syscall) with the GVL released. 4. Because the interrupt is masked, the existing `RB_NOGVL_INTR_FAIL` check does not trip, the native wait is entered, and — if nothing else wakes it — the wait can block indefinitely. The pending interrupt is never observed. This is not hypothetical: it was hit in production through `async-container` and `io-event`, where a scheduler entering a native selector wait could hang because a pending (masked) interrupt was not noticed before the wait began. A blocking operation that is skipped because the thread has pending work should be treated the same way as an interrupted wait: return immediately without entering the wait, and let the caller unwind so Ruby can process the interrupt. ## Proposal Add the flag: ```c #define RB_NOGVL_PENDING_INTERRUPT_FAIL (0x8) ``` Semantics when the flag is set: - If the current thread has pending interrupts (as reported by the thread's pending-interrupt queue, *including* interrupts masked by `Thread.handle_interrupt`), `rb_nogvl()` does **not** call `func`. It returns `0`. - Otherwise `rb_nogvl()` behaves as usual: it enters the blocking region, calls `func`, and preserves `func`'s resulting `errno`. The check is performed both as an early pre-check (before any of the blocking-region machinery runs) and again inside the blocking-region setup, to close the window between the pre-check and the point where the GVL is released. ## Relationship to existing flags - `RB_NOGVL_INTR_FAIL` (`0x1`) reacts to *deliverable* VM interrupts (`RUBY_VM_INTERRUPTED_ANY`). It does not consider interrupts deferred by `Thread.handle_interrupt`. - `RB_NOGVL_PENDING_INTERRUPT_FAIL` (`0x8`) reacts to *pending* interrupts in the thread's queue, **including masked ones**. This is the key difference: it lets a caller bail out before a native wait even when the interrupt is not currently deliverable, so the caller can unwind to a point where the interrupt can be handled safely. The flags are independent and may be combined with each other and with `RB_NOGVL_UBF_ASYNC_SAFE` / `RB_NOGVL_OFFLOAD_SAFE`. ## Example A common pattern is to have the callback write its result into a struct that is pre-initialised to a sentinel (e.g. `-1`), then report failure once back under the GVL: ```c struct Arguments { int result; }; static void *my_func(void *ptr) { struct Arguments *arguments = ptr; arguments->result = my_syscall(); return NULL; } struct Arguments arguments = {.result = -1}; rb_nogvl(my_func, &arguments, ubf, &arguments, RB_NOGVL_PENDING_INTERRUPT_FAIL); if (arguments.result == -1) { // Either the syscall ran and was interrupted (errno == EINTR), or it was // not run at all because the thread had pending interrupts (errno == 0). rb_sys_fail("my_syscall"); } ``` Note the `errno` caveat for this proposal: on the skip path `errno` is `0`, and `rb_sys_fail()` does not behave well with `errno == 0`. A caller that wants to funnel both cases through `rb_sys_fail()` should normalise it: ```c if (arguments.result == -1) { if (errno == 0) errno = EINTR; // skip path leaves errno == 0 rb_sys_fail("my_syscall"); } ``` See "Errno handling" below for what `errno == EINTR` vs `errno == 0` tells you. Extensions can feature-detect the flag at build time so they keep working on older Rubies: ```c #ifdef RB_NOGVL_PENDING_INTERRUPT_FAIL flags |= RB_NOGVL_PENDING_INTERRUPT_FAIL; #endif ``` ## Errno handling On the pending-interrupt skip path, `rb_nogvl()` returns `0` with `errno == 0`. This matches the existing skip path used by `RB_NOGVL_INTR_FAIL`: when the function is never called, `errno` is restored to its initial value (`0`). The flag does not otherwise change `rb_nogvl()`'s `errno` behaviour, so this change is purely additive and carries no compatibility risk for existing extensions. For a caller, when an operation reports "no result" (e.g. `result == -1`), the two interesting outcomes can be told apart by `errno`: - `errno == EINTR` — the function **did** run and its syscall was actually interrupted (the conventional `EINTR`). Some side effects may have occurred. - `errno == 0` — the function did **not** run: it was skipped before entering the blocking region, either by `RB_NOGVL_PENDING_INTERRUPT_FAIL` (pending, possibly masked, interrupts) or by `RB_NOGVL_INTR_FAIL`. So for this proposal, `result == -1 && (errno == EINTR || errno == 0)` means the operation was not executed, or was interrupted — in both cases the caller should unwind and let Ruby process interrupts. An `errno` of `0` on a skipped callback is admittedly not very ergonomic (it forces the `if (errno == 0) errno = EINTR;` dance above before `rb_sys_fail()`). Making the skip paths report `EINTR` directly would remove that wrinkle, but it also erases the `EINTR`-vs-`0` distinction above (you could no longer tell a truly-interrupted syscall from a never-run one). That trade-off is a separate concern and may be proposed independently; this proposal keeps the existing behaviour and stays focused on the new flag. ## Implementation A reference implementation is available: - `RB_NOGVL_PENDING_INTERRUPT_FAIL` flag: <https://github.com/ruby/ruby/pull/17553> Downstream user with feature detection and a fallback for older Rubies: - io-event: <https://github.com/socketry/io-event/pull/197> The focused CRuby C-API specs (`spec/ruby/optional/capi/thread_spec.rb`) cover the new flag: the function is not called when the current thread has masked pending interrupts, and `errno` is `0`. -- https://bugs.ruby-lang.org/

1 2