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

[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:123923] [Ruby Bug#21716] YJIT panic: "all PendingBranchRefs should be unique" in net/http response reading (infinite unwind loop)
by angelim＠angelim.com.br (Alexandre Angelim) 22 Jan '26

22 Jan '26

Issue #21716 has been reported by angelim(a)angelim.com.br (Alexandre Angelim). ---------------------------------------- Bug #21716: YJIT panic: "all PendingBranchRefs should be unique" in net/http response reading (infinite unwind loop) https://bugs.ruby-lang.org/issues/21716 * Author: angelim(a)angelim.com.br (Alexandre Angelim) * Status: Open * ruby -v: ruby 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We encountered a YJIT panic in production that caused the process to enter an infinite logging loop for several hours. The panic occurs within `yjit/src/core.rs` when handling branch references. The trigger appears to be in `net/http`, specifically when reading a response body (possibly involving chunked encoding or zlib) inside a Datadog trace transport flush. Key Observations: The Panic: YJIT fails with all PendingBranchRefs should be unique when ready to construct a Block. The Loop: After the panic, the process fails to exit and instead logs `rust_begin_unwind` and `try_fold` iterator errors repeatedly, filling logs for hours. System Configuration Ruby Version: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +YJIT +PRISM [aarch64-linux] Environment: Linux aarch64 (AWS Graviton/ARM) Reproduction Context While we cannot provide a standalone reproduction script yet, the crash happens intermittently during a Net::HTTP request initiated by datadog-ruby (v2.17.0) to flush traces to a Unix socket, which is wrapped by sentry-ruby (v5.26.0). Ruby Location: `/gems/net-http-0.6.0/lib/net/http/response.rb:604` Rust Location: `./yjit/src/core.rs:2403:27` Backtrace & Logs ``` ruby: YJIT has panicked. More info to follow... thread '<unnamed>' panicked at 'all PendingBranchRefs should be unique when ready to construct a Block', ./yjit/src/core.rs:2403:27 stack backtrace: 0: rust_begin_unwind at /rustc/.../library/std/src/panicking.rs:578:5 ... 28: yjit::core::branch_stub_hit at /workspace/ruby-3.4.7/yjit/src/core.rs:3492:9 /gems/net-http-0.6.0/lib/net/http/response.rb:604: [BUG] YJIT: panicked at 'all PendingBranchRefs should be unique when ready to construct a Block', ./yjit/src/core.rs:2403:27 -- Control frame information ----------------------------------------------- c:0047 p:0049 s:0248 e:000247 BLOCK /gems/net-http-0.6.0/lib/net/http/response.rb:604 c:0046 p:0098 s:0243 e:000242 METHOD /gems/net-http-0.6.0/lib/net/http/response.rb:588 c:0045 p:0004 s:0235 e:000234 METHOD /gems/net-http-0.6.0/lib/net/http/response.rb:593 ... c:0039 p:0033 s:0196 e:000195 BLOCK /gems/sentry-ruby-5.26.0/lib/sentry/net/http.rb:44 ... c:0033 p:0023 s:0158 e:000157 METHOD /gems/datadog-2.17.0/lib/datadog/core/transport/http/adapters/unix_socket.rb:43 c:0032 p:0066 s:0152 e:000151 METHOD /gems/datadog-2.17.0/lib/datadog/core/transport/http/adapters/net.rb:77 ``` The stack suggests the crash happens during `branch_stub_hit` resolution. The presence of sentry-ruby and datadog suggests complex interaction with Net::HTTP patching. The infinite loop of logs following the crash looks like this (repeated): ``` /usr/lib/libruby.so.3.4(try_fold<alloc::vec::into_iter::IntoIter<alloc::rc::Rc<yjit::core::PendingBranch> ... `` This suggests the panic handler itself is tripping over the corrupted `PendingBranch` state. We encountered a YJIT panic in production that caused the process to enter an infinite logging loop for several hours. The panic occurs within `yjit/src/core.rs` when handling branch references. The trigger appears to be in `net/http`, specifically when reading a response body (possibly involving chunked encoding or zlib) inside a Datadog trace transport flush. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124596] [Ruby Bug#21845] Need to rebuild C extension of bundled gems after bumping RUBY_ABI_VERSION
by hsbt (Hiroshi SHIBATA) 20 Jan '26

20 Jan '26

Issue #21845 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21845: Need to rebuild C extension of bundled gems after bumping RUBY_ABI_VERSION https://bugs.ruby-lang.org/issues/21845 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I have encountered an issue where fiddle tests are not executed when running `make test-bundled-gems`, so I investigated the conditions for reproducing the issue. It caused by `RUBY_ABI_VERSION`. If I bumped `RUBY_ABI_VERSION` to `2` from `1`, we can't load `.bundle/extensions/arm64-darwin-25/4.1.0+2/fiddle-1.1.8/fiddle.bundle` ``` diff --git a/include/ruby/internal/abi.h b/include/ruby/internal/abi.h index e6d1fa7e8f3..0c99d93bf9b 100644 --- a/include/ruby/internal/abi.h +++ b/include/ruby/internal/abi.h @@ -24,7 +24,7 @@ * In released versions of Ruby, this number is not defined since teeny * versions of Ruby should guarantee ABI compatibility. */ -#define RUBY_ABI_VERSION 1 +#define RUBY_ABI_VERSION 2 /* Windows does not support weak symbols so ruby_abi_version will not exist * in the shared library. */ ``` ``` diff --git a/lib/fiddle.rb b/lib/fiddle.rb index f242de8..12b8277 100644 --- a/lib/fiddle.rb +++ b/lib/fiddle.rb @@ -1,7 +1,11 @@ # frozen_string_literal: true if RUBY_ENGINE == 'ruby' - require 'fiddle.so' + begin + require 'fiddle.so' + rescue LoadError => e + puts e.message + end else require 'fiddle/ffi_backend' end @@ -9,6 +13,7 @@ require 'fiddle/function' require 'fiddle/version' + module Fiddle if RUBY_ENGINE != 'ruby' # FFI backend def self.last_error ``` I rebuild ruby with `make -j` and run `make test-bundled-gems`. ``` ❯ make test-bundled-gems BUNDLED_GEMS=fiddle generating known_errors.inc generating encdb.h generating enc.mk known_errors.inc unchanged fetching v1.1.8 ... encdb.h unchanged making srcs under enc making enc generating transdb.h transdb.h unchanged generating makefiles ext/configure-ext.mk making trans making encs ext/configure-ext.mk unchanged generating makefile exts.mk exts.mk unchanged generating known_errors.inc known_errors.inc unchanged checking out v1.1.8 (v=1.1.8) ... M lib/fiddle.rb HEAD is now at 310b843 Add 1.1.8 entry Testing the fiddle gem ["/Users/hsbt/Documents/github.com/ruby/ruby/exe/ruby", "-C", "/Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle", "/Users/hsbt/Documents/github.com/ruby/ruby/.bundle/bin/rake", "test"] Dummy `compile` task defined in /Users/hsbt/Documents/github.com/ruby/ruby/gems/lib/rake/extensiontask.rb compile => Dummy `compile` task defined in /Users/hsbt/Documents/github.com/ruby/ruby/gems/lib/rake/extensiontask.rb compile => /Users/hsbt/Documents/github.com/ruby/ruby/exe/ruby test/run.rb /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/test/fiddle/test_pointer.rb:288: warning: ambiguous first argument; put parentheses or a space even after `-` operator incompatible ABI version of binary - /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/extensions/arm64-darwin-25/4.1.0+2/fiddle-1.1.8/fiddle.bundle /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/lib/fiddle.rb:56:in '<module:Fiddle>': uninitialized constant Fiddle::WINDOWS (NameError) if WINDOWS ^^^^^^^ from /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/lib/fiddle.rb:17:in '<top (required)>' from /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/test/fiddle/helper.rb:5:in 'Kernel#require' from /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/test/fiddle/helper.rb:5:in '<top (required)>' from /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/test/fiddle/test_pointer.rb:3:in 'Kernel#require_relative' from /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/test/fiddle/test_pointer.rb:3:in '<top (required)>' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:118:in 'Kernel#require' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:118:in 'block in Test::Unit::Collector::Load#collect_file' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:140:in 'Test::Unit::Collector::Load#add_load_path' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:116:in 'Test::Unit::Collector::Load#collect_file' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:91:in 'block in Test::Unit::Collector::Load#collect_recursive' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:89:in 'Array#each' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:89:in 'Test::Unit::Collector::Load#collect_recursive' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:47:in 'block (2 levels) in Test::Unit::Collector::Load#collect' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:44:in 'Array#each' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:44:in 'block in Test::Unit::Collector::Load#collect' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:140:in 'Test::Unit::Collector::Load#add_load_path' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/collector/load.rb:38:in 'Test::Unit::Collector::Load#collect' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/autorunner.rb:109:in 'block in <class:AutoRunner>' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/autorunner.rb:490:in 'Test::Unit::AutoRunner#run' from /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/test-unit-3.7.7/lib/test/unit/autorunner.rb:69:in 'Test::Unit::AutoRunner.run' from test/run.rb:21:in '<main>' rake aborted! Command failed with status (1): [/Users/hsbt/Documents/github.com/ruby/ruby/exe/ruby test/run.rb] /Users/hsbt/Documents/github.com/ruby/ruby/gems/src/fiddle/Rakefile:5:in 'block in <top (required)>' /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/rake-13.3.1/exe/rake:27:in '<top (required)>' Tasks: TOP => test (See full trace by running task with --trace) Tests failed with exit code 1 Failed gems: fiddle make: *** [uncommon.mk:1599: yes-test-bundled-gems-run] Error 1 ``` Simple confirmation is here: ``` ❯ ./exe/ruby -e "require_relative '.bundle/extensions/arm64-darwin-25/4.1.0+2/fiddle-1.1.8/fiddle.bundle'" -e:1:in 'Kernel#require_relative': incompatible ABI version of binary - /Users/hsbt/Documents/github.com/ruby/ruby/.bundle/extensions/arm64-darwin-25/4.1.0+2/fiddle-1.1.8/fiddle.bundle (LoadError) from -e:1:in '<main>' ``` I fixed this with `git clean -fxd` and delete all old artifacts or use fresh clone of `ruby/ruby` repository. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124592] [Ruby Feature#21843] Simple Priority Scheduler
by luke-gru (Luke Gruber) 19 Jan '26

19 Jan '26

Issue #21843 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #21843: Simple Priority Scheduler https://bugs.ruby-lang.org/issues/21843 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- Hi, There's a problem with Ruby's scheduler that I want to solve. # The Problem Since Ruby schedules threads using round-robin inside a Ractor, threads doing I/O after only running for a short time are punished. Once the I/O finishes, they are put on the back of the ready queue and have to wait for max `N * 100ms` where `N` is the number of threads in the queue before it (100ms is the quantum for threads with normal `Thread#priority`). Most ruby threads don't use up their full timeslice (I'm guessing), but they are still punished by CPU hogs. I would like to more fairly run threads that are punished for giving up their timeslice early. My goals for such a scheduler are the following: # The Goal * Threads that give up their timeslice early are rewarded with a priority boost. * Simple approach (no vruntime like Linux's CFS, not too many runqueues, etc) with easy to understand design and implementation. * No starvation. There can be no worst-case scenario where a thread is stuck in a queue. * Make perf. gains for programs with threads that perform mixed workloads of I/O and CPU. * In worst-case scenarios (100% CPU threads with background I/O threads) don't slow down by a considerable amount. # The Design ### Queues and Dequeue The design is simple and uses 2 queues `high` and `low`. The scheduler tracks the order each thread is put in a queue, and the order is global for both queues. If a thread on the head of the `high` queue was put there before the thread on the head of the `low` queue, the `high` thread is dequeued. If the `low` thread was enqueued first, then this is considered a "priority decision". Half the time during a priority decision, the thread from `high` is dequeued, otherwise `low` is dequeued. ### Enqueue Which queue is a thread placed on when it is ready to run? * When there are no threads in any queue, we always pick `high`. * If we just performed I/O and didn't even use up 1/10 of our timeslice, we are enqueued in `high`. We can do this max 3 times in a row, and only if `Thread#priority >= 0`. * If we were in the low queue, every 4 "enqueues" we check the accumulated timeslice time taken during the last 4 timeslices. If that time is less than 1/2 of our quantum, we are enqueued in `high`. This can only happen if `Thread#priority >= 0`. * Otherwise, we are enqueued in `low`. This design is very conservative, and attempts not to punish CPU-intensive threads. # Testing + Benchmarking I would like to add a suite of tests to `ruby-bench` that would test the scheduler in different scenarios, including scenarios in which it could potentially perform worse than round-robin. This set of benchmarks would be useful going forward when making any changes to the scheduler. I already have several scripts that I've used for testing my draft PR. # Feature Flags and API I don't know if a feature like this would need to be behind a flag, marked as experimental, etc. Maybe it could even be enabled by `Thread.scheduler = :priority`. # Alternatives I'm open to any ideas and different approaches. I know that prioritizing more fairness in timeslice time is one approach, but we could also simply enqueue threads that are marked `Thread#priority > 0` more often in the `high` queue. Right now their timeslice is increased but they don't get special treatment in the queues. I have a draft branch here: https://github.com/ruby/ruby/compare/master...luke-gruber:ruby:priority_sch… Let me know your thoughts. Thanks! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124591] Invitation to RubyKaigi 2026
by Akira Matsuda 19 Jan '26

19 Jan '26

To: ruby-core committers We’re happy to announce that registration for RubyKaigi 2026 is now open! As is tradition, all Ruby core team members (with direct commit access to the Git repository) are invited to attend the conference free of charge. Please register via the following ticketing URL: https://ti.to/rubykaigi/2026/with/8jz7nne4osc For the “Committer account name” field, please enter the account name listed in the Ruby committer email list on GitHub: https://github.com/ruby/ruby-commit-hook/blob/master/config/email.yml Alternatively, you may use your Redmine account name, SVN account name, or any equivalent identifier that clearly identifies you as a Ruby core committer. See you in Hakodate! 🌟 -- Akira Matsuda / RubyKaigi 2026 team

1 0

[ruby-core:124571] [Ruby Bug#21841] bootstraptest is failed with OpenSUSE leap 16.0
by hsbt (Hiroshi SHIBATA) 19 Jan '26

19 Jan '26

Issue #21841 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21841: bootstraptest is failed with OpenSUSE leap 16.0 https://bugs.ruby-lang.org/issues/21841 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I update OpenSUSE leap instance to 16.0 from 15.x. After that, bootstraptest is failing with Ruby 3.2-3.4. Ruby 4.0 and master are working fine. Ruby 3.4: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.4/log/20260115T223828Z.… ``` stderr output is not empty bootstraptest.test_jump.rb_299_735.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.8 (2026-01-06 revision c04363c0a0) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000ad0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055595d2a3ea0 RBP: 0x000000000000000d RSP: 0x00007ffc91829260 RAX: 0x000000000000000e RBX: 0x0000555990437ae0 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000007 RSI: 0x00007fd33607f081 R8: 0x045043922b485040 R9: 0x00007fd33607f081 R10: 0x0c0e0301ac9c2fcf R11: 0x000055595d56bf70 R12: 0x00007fd33607f0f1 R13: 0x00007fd33607f079 R14: 0x00005559905f88a8 R15: 0x00007fd33607f0ea EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_print_backtrace+0x5) [0x55595d35b136] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/vm_dump.c:823 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/vm_dump.c:1155 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_bug_for_fatal_signal+0xf7) [0x55595d0fc3c7] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/error.c:1130 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(sigsegv+0x42) [0x55595d286f42] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/signal.c:935 /lib64/libc.so.6(__restore_rt+0x0) [0x7fd335cb2090] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(search_nonascii+0xcb) [0x55595d2a3ea0] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/string.c:729 ... ``` Ruby 3.3: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.3/log/20260115T224711Z.… ``` stderr output is not empty bootstraptest.test_syntax.rb_630_1458.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.3.10 (2025-12-15 revision 10876c271b) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0002 p:---- s:0006 e:000005 CFUNC :detailed_message c:0001 p:0000 s:0003 E:0018b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.test_syntax.rb_630_1458.rb:0:in `detailed_message' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00005613f2267560 RBP: 0x000000000000000a RSP: 0x00007ffe1fb01f60 RAX: 0x000000000000000b RBX: 0x00005613ff3fb5c0 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000005 RSI: 0x00005613ff5537c7 R8: 0x0000000000000000 R9: 0x00005613ff5537c7 R10: 0x0000000000802005 R11: 0x00005613ff3e0950 R12: 0x00005613ff553824 R13: 0x00005613ff5537c7 R14: 0x0000000000000001 R15: 0x00005613ff55381d EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_print_backtrace+0x11) [0x5613f23190df] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/vm_dump.c:820 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/vm_dump.c:1151 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_bug_for_fatal_signal+0xf7) [0x5613f20cac37] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/error.c:1065 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(sigsegv+0x4b) [0x5613f224cedb] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/signal.c:928 /lib64/libc.so.6(__restore_rt+0x0) [0x7fce945e2090] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(search_nonascii+0xeb) [0x5613f2267560] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/string.c:598 ... ``` Ruby 3.2: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.2/log/20260115T225525Z.… ``` /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.2.10 (2026-01-14 revision a3a6d25788) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0013 p:---- s:0156 e:000155 CFUNC :% c:0012 p:1572 s:0151 E:001aa8 METHOD /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518 c:0011 p:0060 s:0106 e:000105 METHOD ./ext/extmk.rb:144 c:0010 p:0067 s:0099 e:000098 METHOD ./ext/extmk.rb:565 c:0009 p:0043 s:0091 e:000090 TOP /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/ext/-test-/RUBY_ALIGNOF/extconf.rb:6 [FINISH] c:0008 p:---- s:0088 e:000087 CFUNC :load c:0007 p:0026 s:0083 e:000082 BLOCK ./ext/extmk.rb:229 c:0006 p:0022 s:0080 e:000079 METHOD /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:324 c:0005 p:0554 s:0076 e:000075 METHOD ./ext/extmk.rb:225 c:0004 p:0039 s:0045 e:000044 BLOCK ./ext/extmk.rb:652 [FINISH] c:0003 p:---- s:0040 e:000039 CFUNC :each c:0002 p:0859 s:0036 E:002170 EVAL ./ext/extmk.rb:648 [FINISH] c:0001 p:0000 s:0003 E:001870 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ./ext/extmk.rb:648:in `<main>' ./ext/extmk.rb:648:in `each' ./ext/extmk.rb:652:in `block in <main>' ./ext/extmk.rb:225:in `extmake' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:324:in `open' ./ext/extmk.rb:229:in `block in extmake' ./ext/extmk.rb:229:in `load' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/ext/-test-/RUBY_ALIGNOF/extconf.rb:6:in `<top (required)>' ./ext/extmk.rb:565:in `create_makefile' ./ext/extmk.rb:144:in `create_makefile' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518:in `create_makefile' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518:in `%' -- Machine register context ------------------------------------------------ RIP: 0x000055b195f34b60 RBP: 0x00007f843e87b62f RSP: 0x00007ffd2427ffe8 RAX: 0x0000000000000000 RBX: 0x000055b1a8576710 RCX: 0x00007f843e87b637 RDX: 0x0000000000000000 RDI: 0x00007f843e87b673 RSI: 0x0000000000000008 R8: 0x00007f843e87b67a R9: 0x0000000000000004 R10: 0x00007f843e87b637 R11: 0x00007f843e87b610 R12: 0x0000000000000078 R13: 0x0000000000100000 R14: 0x00007f843e87b67a R15: 0x00007f843e87b610 EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_print_backtrace+0x11) [0x55b195feac68] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/vm_dump.c:785 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/vm_dump.c:1080 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_bug_for_fatal_signal+0xe7) [0x55b195d968d7] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/error.c:813 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(sigsegv+0x4b) [0x55b195f1f97b] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/signal.c:965 /lib64/libc.so.6(__restore_rt+0x0) [0x7f843ec46090] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(search_nonascii+0xf0) [0x55b195f34b60] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/string.c:660 ... ``` Does anyone know of a commit that might have fix this issue? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124587] [Ruby Bug#8743] Inconsistent behaviour calling public_methods on class (Plus documentation slightly ambiguous)
by trinistr (Alexander Bulancov) 18 Jan '26

18 Jan '26

Issue #8743 has been updated by trinistr (Alexander Bulancov). I've been working on some tests using `public_methods`, and was bitten by this. I think a documentation update is definitely needed. Docs shouldn't straight-up lie. Though I personally think that Module (or Class?) should just have different implementations of these methods. Current behavior makes some sense for instances, but for classes it's plain weird. ---------------------------------------- Bug #8743: Inconsistent behaviour calling public_methods on class (Plus documentation slightly ambiguous) https://bugs.ruby-lang.org/issues/8743#change-116168 * Author: stestagg (Steve Stagg) * Status: Closed * ruby -v: ruby 2.1.0dev (2013-08-06 trunk 42401) [x86_64-darwin12.4.0] ---------------------------------------- =begin = Background I was trying to identify classes on which a specific class method (def self.xx) was actually defined (in the case of multiple levels of inheritance). This currently doesn't seem to be possible, although the docs suggest that calling class.public_methods(false) should do this. While investigating, I discovered that the behaviour of calling instance.public_methods(false) is not consistent with that of calling class.public_methods(false) [They should be different, of course, but the behaviour should be consistent]. The attached test script highlights this. = Steps to Reproduce Run the attached ruby script = Expected Result Ideally, all tests pass, but at `least test_consistent_behaviour` should pass = Actual Results test_this_is_what_i_expect, and test_consistent_behaviour both fail. = Example test output steves@sapphire ~/s/t/ruby> env RUBYLIB=./lib ./ruby ~/foo.rb Run options: # Running tests: [2/5] PublicMethodsTest#test_consistent_behaviour = 0.00 s 1) Failure: PublicMethodsTest#test_consistent_behaviour [/Users/steves/foo.rb:73]: Differences: bar. "bar" is inherited from A, but doesn't include methods inherited from Object! [5/5] PublicMethodsTest#test_this_is_what_i_expect = 0.00 s 2) Failure: PublicMethodsTest#test_this_is_what_i_expect [/Users/steves/foo.rb:59]: Differences: allocate, new, superclass. Finished tests in 0.005998s, 833.6112 tests/s, 2834.2781 assertions/s. 5 tests, 17 assertions, 2 failures, 0 errors, 0 skips ruby -v: ruby 2.1.0dev (2013-08-06 trunk 42401) [x86_64-darwin12.4.0] Seen on ruby 1.8, 2.0 and trunk =end ---Files-------------------------------- foo.rb (2.22 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124408] [Ruby Bug#21816] iseq code_location miss calculated indent
by zzak (zzak _) 16 Jan '26

16 Jan '26

Issue #21816 has been reported by zzak (zzak _). ---------------------------------------- Bug #21816: iseq code_location miss calculated indent https://bugs.ruby-lang.org/issues/21816 * Author: zzak (zzak _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TBH, I'm not really sure if that title matches the problem here, but I can produce this issue with the following test: ```ruby # bug.rb # note the indentation of the callable callable = -> { puts "Hello, World!" } iseq = RubyVM::InstructionSequence.of(callable) pp iseq.to_a pp iseq.to_a[4] pp iseq.to_a[4][:code_location][1] ``` Ruby 4.0.0: ``` $ ruby -v bug.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 0, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 15 ``` Ruby 4.1.0: ``` $ ruby -v bug.rb ruby 4.1.0dev (2025-12-30T18:02:00Z master 9d37155cfc) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 13 ``` For context: This second value being 13 instead of 15 is causing Rails tests to fail: https://buildkite.com/rails/rails-nightly/builds/3447#019b710f-e78a-405f-82… We want: ``` { @object.num } ``` But we get: ``` -> { @object.num } ``` I am pretty sure using the same version of `prism`: ``` /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.1.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.0.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) ``` We use this data to get the original source string of a block we use to decorate the `assert_difference` assertion: https://github.com/rails/rails/blob/3d31d593e6cf0f82fa9bd0338b635af2f30d627… https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#m… -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124054] [Ruby Misc#21768] Remove deprecated functions
by nobu (Nobuyoshi Nakada) 16 Jan '26

16 Jan '26

Issue #21768 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21768: Remove deprecated functions https://bugs.ruby-lang.org/issues/21768 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124047] [Ruby Feature#21766] Pathname + FileUtils making sweet music together
by gurgeous (Adam Doppelt) 16 Jan '26

16 Jan '26

Issue #21766 has been reported by gurgeous (Adam Doppelt). ---------------------------------------- Feature #21766: Pathname + FileUtils making sweet music together https://bugs.ruby-lang.org/issues/21766 * Author: gurgeous (Adam Doppelt) * Status: Open ---------------------------------------- I love Pathname. I love FileUtils. Let's bring these two classes EVEN CLOSER TOGETHER by adding some tragically missing helpers. Something like this, perhaps? ``` ruby class Pathname def mkdir_p(...) = FileUtils.mkdir_p(@path, ...) def ln(...) = FileUtils.ln(@path, ...) def ln_s(...) = FileUtils.ln_s(@path, ...) def ln_sf(...) = FileUtils.ln_sf(@path, ...) def cp(...) = FileUtils.cp(@path, ...) def cp_r(...) = FileUtils.cp_r(@path, ...) def mv(...) = FileUtils.mv(@path, ...) def rm(...) = FileUtils.rm(@path, ...) def rm_r(...) = FileUtils.rm_r(@path, ...) def rm_rf(...) = FileUtils.rm_rf(@path, ...) end ``` There are some concerns about making pathname.rb more dependent on FileUtils, which I understand. What's the best way forward? Let's do it! (also see https://github.com/ruby/pathname/issues/64 and https://github.com/ruby/pathname/issues/72) -- https://bugs.ruby-lang.org/

5 6