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

[ruby-core:123449] [Ruby Bug#21633] A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals.
by ioquatix (Samuel Williams) 12 Feb '26

12 Feb '26

Issue #21633 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21633: A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals. https://bugs.ruby-lang.org/issues/21633 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- The gRPC gem calls `rb_thread_call_without_gvl` in a loop, and doesn't exit when interrupts are delivered if `Thread.handle_interrupt(::SignalException => :never)` is used by the scheduler to create a safe point for asynchronous signal handling. While this may not be considered a bug in any particular part of the system, the combination of the behaviour creates a situation where gRPC can hang for a long time and ignores SIGINT / SIGTERM. ## gRPC Failure Analysis From [`src/ruby/ext/grpc/rb_completion_queue.c`](https://github.com/samuel-williams-shopify/grpc/blob/debug/src/ruby/ext/grpc/rb_completion_queue.c): ```c static void unblock_func(void* param) { next_call_stack* const next_call = (next_call_stack*)param; next_call->interrupted = 1; // ← SIGINT causes this flag to be set } grpc_event rb_completion_queue_pluck(grpc_completion_queue* queue, void* tag, gpr_timespec deadline, const char* reason) { // ... do { next_call.interrupted = 0; // ← Reset flag rb_thread_call_without_gvl(grpc_rb_completion_queue_pluck_no_gil, (void*)&next_call, unblock_func, (void*)&next_call); if (next_call.event.type != GRPC_QUEUE_TIMEOUT) break; } while (next_call.interrupted); // ← The problem! If interrupted, LOOP AGAIN! return next_call.event; } ``` The loop explicitly retries after interruption, making SIGINT/SIGTERM ineffective. This might be considered the expected behaviour if `Thread.handle_interrupt` is used. However, the goal of `Thread.handle_interrupt` in the fiber scheduler is to create a safe point for signal handling, not to prevent them completely. Since this loop never yields back to the scheduler, no such chance exists, and the loop will continue indefinitely. As `rb_thread_call_without_gvl` invokes `vm_check_ints_blocking`, one solution is to yield to the scheduler in the case that there are pending interrupts. This gives the scheduler a chance to handle the incoming SIGINT / SIGTERM signals at the safe point. For a full reproduction of the issue using gRPC: https://github.com/samuel-williams-shopify/grpc-interrupt For the proposed fix: https://github.com/ruby/ruby/pull/14700 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 09 Feb '26

09 Feb '26

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:118784] [Ruby master Feature#20664] Add `before` and `until` options to Enumerator.produce
by knu (Akinori MUSHA) 08 Feb '26

08 Feb '26

Issue #20664 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #20664: Add `before` and `until` options to Enumerator.produce https://bugs.ruby-lang.org/issues/20664 * Author: knu (Akinori MUSHA) * Status: Open ---------------------------------------- Enumerator.produce provides a nice way to generate an infinite sequence but is a bit awkward to define how to end a sequence. It lacks a simple and easy way to produce typical finite sequences in an intuitive syntax. This proposal attempts to solve the problem by adding these two options to the method: - `before`: when provided, it is used as a predicate to determine if an iteration should end before a generated value gets yielded. - `until`: when provided, it is used as a predicate to determine if an iteration should end until after a generated value gets yielded. Any value that responds to `to_proc` and returns a `Proc` object is accepted in these options. A typical use case for the `before` option is traversing a tree structure to iterate over the ancestors or following/preceding siblings of a node. The `until` option can be used when there is a clear definition of the "last" value to yield. ```ruby enum = Enumerator.produce(File, before: :nil?, &:superclass) enum.to_a #=> [File, IO, Object, BasicObject] enum = Enumerator.produce(3, until: :zero?, &:pred) enum_to_a #=> [3, 2, 1, 0] ``` ---Files-------------------------------- 0001-Add-before-and-until-options-to-Enumerator.produce.patch (10.7 KB) -- https://bugs.ruby-lang.org/

6 12

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 07 Feb '26

07 Feb '26

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

9 12

[ruby-core:121982] [Ruby Bug#21323] irb fails to start with Namespace
by Eregon (Benoit Daloze) 07 Feb '26

07 Feb '26

Issue #21323 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21323: irb fails to start with Namespace https://bugs.ruby-lang.org/issues/21323 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ irb irb(main):001> 6 * 7 => 42 $ RUBY_NAMESPACE=1 irb /home/eregon/prefix/ruby-master/bin/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' zsh: exit 1 RUBY_NAMESPACE=1 irb ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 06 Feb '26

06 Feb '26

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 21

[ruby-core:121993] [Ruby Bug#21326] Instruction generation differences between parse.y and prism for `def a(x, ...); b(...); end`
by zenspider (Ryan Davis) 25 Jan '26

25 Jan '26

Issue #21326 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21326: Instruction generation differences between parse.y and prism for `def a(x, ...); b(...); end` https://bugs.ruby-lang.org/issues/21326 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: ruby 3.5.0dev * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Diff instructions using: ```sh DUMP="puts RubyVM::InstructionSequence.compile(ARGV.first).disasm.gsub(/^\d+ /, '')" RUBY="def a(x, ...); b(...); end" env -u RUBYOPT \ diff -U99 \ <(./build/ruby -v --parser=parse.y -e "$DUMP" "$RUBY" 2>/dev/null) \ <(./build/ruby -v --parser=prism -e "$DUMP" "$RUBY" 2>/dev/null) ``` shows: ```diff --- /dev/fd/63 2025-05-10 14:46:37 +++ /dev/fd/62 2025-05-10 14:46:37 @@ -1,17 +1,18 @@ -ruby 3.5.0dev (2025-05-10T17:32:21Z master 98667f82d2) +GC [arm64-darwin24] +ruby 3.5.0dev (2025-05-10T17:32:21Z master 98667f82d2) +PRISM +GC [arm64-darwin24] == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,26)> definemethod :a, a ( 1)[Li] putobject :a leave == disasm: #<ISeq:a@<compiled>:1 (1,0)-(1,26)> local table (size: 5, argc: 1 [opts: 0, rest: 1, post: 0, block: 3, kw: -1@-1, kwrest: 2]) [ 5] x@0<Arg> [ 4] "*"@1<AnonRest>[ 3] "**"@2<AnonKwrest>[ 2] "&"@3<Block>[ 1] "..."@4 putself ( 1)[LiCa] getlocal_WC_0 "*"@1 -splatarray false +splatarray true getlocal_WC_0 "**"@2 getblockparamproxy "&"@3, 0 splatkw -send <calldata!mid:b, argc:2, ARGS_SPLAT|ARGS_BLOCKARG|FCALL|KW_SPLAT>, nil +splatkw +send <calldata!mid:b, argc:2, ARGS_SPLAT|ARGS_SPLAT_MUT|ARGS_BLOCKARG|FCALL|KW_SPLAT>, nil leave [Re] ``` PR here: https://github.com/ruby/ruby/pull/13299 goes back to at least 3.4. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116935] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nagachika (Tomoyuki Chikanaga) 22 Jan '26

22 Jan '26

Issue #18743 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ruby_3_2 5e4606423da96c2e26b00981c22bddfce0d970bf merged revision(s) f15123c34ce80f3928612befe2a9aaf4c9d27fda. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-106970 * Author: sos4nt (Stefan Schüßler) * Status: Closed * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123414] [Ruby Bug#21629] Ruby-3.4.7 fails to build using clang / llvm
by debo (David Bohman) 22 Jan '26

22 Jan '26

Issue #21629 has been reported by debo (David Bohman). ---------------------------------------- Bug #21629: Ruby-3.4.7 fails to build using clang / llvm https://bugs.ruby-lang.org/issues/21629 * Author: debo (David Bohman) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-darwin16] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Here is the error I encountered. This is using clang version 21.1.3 as the compiler toolchain on Darwin. ``` DYLD_LIBRARY_PATH=.:../../.. ASAN_OPTIONS=detect_leaks=0 "clang -I../../../.ext/include/x86_64-darwin16 -I../../../../ruby-3.4.7/include -I../../../../ruby-3.4.7/ext/-test-/public_header_warnings -I/usr/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef -fno-common -pipe -D_TEST_OK -Werror -c conftest.c" In file included from conftest.c:1: In file included from ../../../../ruby-3.4.7/include/ruby.h:38: In file included from ../../../../ruby-3.4.7/include/ruby/ruby.h:28: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic.h:24: In file included from ../../../../ruby-3.4.7/include/ruby/internal/arithmetic/char.h:29: ../../../../ruby-3.4.7/include/ruby/internal/core/rstring.h:398:24: error: default initialization of an object of type 'struct RString' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 398 | struct RString retval; | ^ ../../../../ruby-3.4.7/include/ruby/internal/core/rbasic.h:86:17: note: member 'klass' declared 'const' here 86 | const VALUE klass; | ^ 1 error generated. checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return !!argv[argc]; 6: } /* end */ ``` The configuration is the following: ``` CC=clang CXX=clang++ CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../ruby-3.4.7/configure --enable-shared --with-rdoc=ri,html ``` -- https://bugs.ruby-lang.org/

5 18

[ruby-core:112045] [Ruby master Bug#19378] Windows: Use less syscalls for faster require of big gems
by aidog (Andi Idogawa) 12 Jan '26

12 Jan '26

Issue #19378 has been reported by aidog (Andi Idogawa). ---------------------------------------- Bug #19378: Windows: Use less syscalls for faster require of big gems https://bugs.ruby-lang.org/issues/19378 * Author: aidog (Andi Idogawa) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello 🙂 ## Problem require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby. ## Possible Reason As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times. ## Testfile C:\tmp\speedtest\testrequire.rb: ``` ruby require __dir__ + "/helloworld1.rb" require __dir__ + "/helloworld2.rb" ``` ``` shell ruby --disable-gems C:\tmp\speedtest\testrequire.rb ``` ### Syscalls per File/Directory: 1. CreateFile 2. QueryInformationVolume 3. QueryIdInformation 4. QueryAllInformationFile 5. QueryNameInformationFile 6. QueryNameInformationFile 7. QueryNormalizedNameInformationFile 8. CloseFile ### Files/Directories checked 1. C:\tmp 2. C:\tmp\speedtest 3. C:\tmp\speedtest\helloworld1.rb 4. C:\tmp 5. C:\tmp\speedtest 6. C:\tmp\speedtest\helloworld2.rb For two required files Ruby had to do 8*6 = **48** syscalls. The syscalls orginate from rb_w32_reparse_symlink_p / lstat Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb" Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls. The result for the syscalls don't change in such a short time, so it should be possible to cache it. With require_relative it's twice as many calls. ## Other testcases Same result: ``` ruby File.realpath __dir__ + "/helloworld1.rb" File.realpath __dir__ + "/helloworld2.rb" ``` ``` ruby File.stat __dir__ + "/helloworld1.rb" File.stat __dir__ + "/helloworld2.rb" ``` It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb") ## Request Would it be possible to cache the stat calls when using require? I tried to implement a cache inside the ruby source code, but failed. If not, is there now a way to combine ruby files into one? I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11) ## How to reproduce Ruby versions: At least 3.0+, most likely older ones too. Tested using Ruby Installer 3.1 and 3.2. [Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc… -- https://bugs.ruby-lang.org/

6 7