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

[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:124270] [Ruby Bug#21787] `IO::Buffer` buffer overf
by nobu (Nobuyoshi Nakada) 25 Jan '26

25 Jan '26

Issue #21787 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21787: `IO::Buffer` buffer overf https://bugs.ruby-lang.org/issues/21787 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124616] [Ruby Bug#21848] GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete
by henrik (Henrik A) 24 Jan '26

24 Jan '26

Issue #21848 has been reported by henrik (Henrik A). ---------------------------------------- Bug #21848: GC compaction freezes during code reload with 100% CPU in rb_vm_ci_free -> st_general_delete https://bugs.ruby-lang.org/issues/21848 * Author: henrik (Henrik A) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.1 freezes with 100% CPU usage when garbage collection runs during Rails code reloading (hot reload in development). The process becomes unresponsive and requires kill -9 to terminate. Environment: - Ruby: 4.0.1 (Homebrew, ARM64) - Platform: macOS 15.6.1 (Darwin 24.6.0, Apple Silicon) - Rails: 8.x with Puma 7.2.0 - Mode: Development with code reloading enabled Steps to reproduce: 1. Run a Rails application with Puma in development mode (bundle exec rails server -e development -b 0.0.0.0) 2. Make a several code change to trigger hot reload, reload the site in the browser in between 3. Process freezes with ~100% CPU Expected behavior: Code reloads successfully, GC completes normally. Actual behavior: Process freezes indefinitely at 100% CPU. Stack trace from sample shows GC stuck in hash table lookup while freeing VM call info: ``` gc_sweep (in libruby.4.0.dylib) gc_compact_plane gc_sweep_page gc_sweep_plane rb_gc_obj_free_vm_weak_references rb_vm_ci_free st_general_delete find_table_bin_ind vm_ci_hash_cmp <-- stuck here, spinning ``` Full relevant stack (Puma worker thread): ``` Thread: puma srv tp 005 rb_ary_each -> rb_yield -> invoke_block_from_c_bh -> rb_vm_exec -> int_upto -> rb_yield (nested loops) -> vm_search_method_slowpath0 -> rb_vm_search_method_slowpath -> newobj_of -> newobj_cache_miss -> gc_continue -> gc_sweep -> gc_compact_plane -> gc_sweep_page -> gc_sweep_plane -> rb_gc_obj_free_vm_weak_references -> rb_vm_ci_free -> st_general_delete -> find_table_bin_ind -> vm_ci_hash_cmp ``` Workaround: Disabling auto-compaction prevents the freeze: GC.auto_compact = false Analysis: The freeze occurs during GC sweep/compaction when freeing cached VM call info entries (rb_vm_ci_free). This is triggered by code reloading which invalidates method caches. The GC appears to get stuck in an infinite loop or extremely slow operation in find_table_bin_ind while looking up entries in the call info hash table. ---Files-------------------------------- rails_stuck.txt (159 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124599] [Ruby Feature#21846] Add a fast path for GC sweeping
by eightbitraptor (Matt V-H) 23 Jan '26

23 Jan '26

Issue #21846 has been reported by eightbitraptor (Matt V-H). ---------------------------------------- Feature #21846: Add a fast path for GC sweeping https://bugs.ruby-lang.org/issues/21846 * Author: eightbitraptor (Matt V-H) * Status: Open ---------------------------------------- [Github PR 15885](https://github.com/ruby/ruby/pull/15885) ## Summary This proposal adds a fast path through the garbage collector's sweep phase that skips expensive cleanup operations for objects that don't require them. Simple embedded objects without external resources, finalizers, or weak references are added directly to the freelist, resulting in a 20-40% reduction in sweep time and 1-2% improvement in overall application performance. ## Background Ruby's garbage collector currently uses a single code path for sweeping all objects. During the sweep phase, every unmarked object goes through `rb_gc_obj_free_vm_weak_references` to clean up entries in the object_id table (`id2ref_tbl`) and generic fields table, followed by `rb_gc_obj_free` for type-specific cleanup and memory deallocation. This is necessary for objects with external resources, but a lot of objects created are "simple" - they have no external allocations, no registered object_id, no generic ivars, and no finalizers. For these simple objects, the sweep phase does significant work even though there's nothing to clean up. Every object is checked against the `id2ref_tbl` table (even if `ObjectSpace._id2ref` was never called), they're checked for finalizers, and they go through type-specific free functions that often just return immediately. In applications that allocate many temporary objects, this overhead accumulates significantly. ## Proposal A new predicate function `gc_sweep_fast_path_p` determines whether an object can skip the expensive cleanup calls. Objects eligible for the fast path are added directly to the freelist after clearing the write barrier unprotected bit. Two conditions always require the slow path: 1. The object has a finalizer (`FL_FINALIZE` flag is set) 2. The object has an observed `object_id` stored in the `id2ref_tbl` (checked via `rb_shape_has_object_id`) If neither condition applies, we move on to some type specific flag checks We use the fast path in these cases: * `T_OBJECT`: Embedded objects only (no heap-allocated instance variable array) * `T_STRING`: Embedded strings that aren't frozen * `T_ARRAY`: Embedded arrays * `T_HASH`: Embedded hashes (ie. no external `st_table`) * `T_BIGNUM`: Embedded bignums * `T_STRUCT`: Embedded structs * `T_FLOAT`, `T_RATIONAL`, `T_COMPLEX` * `T_DATA`: TypedData that is embedded with a NULL or `RUBY_DEFAULT_FREE` dfree function * `T_IMEMO`: Safe subtypes only (constcache, cref, ifunc, memo, svar, throw_data) For all the above types we'll also check whether any generic ivars are registered in the `generic_fields_tbl`. If they have generic ivars set, then we'll use the slow path to clean them up. All other types use the slow path. ### Compatibility Currently this patch is is disabled for modular GC builds (`BUILDING_MODULAR_GC`) because we need access to the `id2ref_tbl`, and I haven't pushed it through the GC API. ## Evaluation ### Benchmark Results All benchmarks were run on an Amazon c5.metal bare-metal VM with turbo boost and ASLR disabled, CPU frequency locked and using the performance governor, and pinned to a single core using `taskset`. GC-specific benchmarks show significant sweep time improvements: ``` Benchmark │ Wall(B) Sweep(B) Mark(B) │ Wall(E) Sweep(E) Mark(E) │ Wall Δ Sweep Δ ───────────────┼────────────────────────────────┼────────────────────────────────┼────────────────── null │ 0.000s 1ms 4ms │ 0.000s 1ms 4ms │ 0% 0% hash1 │ 4.330s 875ms 46ms │ 3.960s 531ms 44ms │ +8.6% +39.3% hash2 │ 6.356s 243ms 988ms │ 6.298s 176ms 1.03s │ +0.9% +27.6% rdoc │ 37.337s 2.42s 1.09s │ 36.678s 2.11s 1.20s │ +1.8% +13.1% binary_trees │ 3.366s 426ms 252ms │ 3.082s 275ms 239ms │ +8.4% +35.4% ring │ 5.252s 14ms 2.47s │ 5.327s 12ms 2.43s │ -1.4% +14.3% redblack │ 2.966s 28ms 41ms │ 2.940s 21ms 38ms │ +0.9% +25.0% ───────────────┼────────────────────────────────┼────────────────────────────────┼────────────────── Legend: (B) = Baseline, (E) = Experiment, Δ = improvement (positive = faster) Wall = total wallclock, Sweep = GC sweeping time, Mark = GC marking time Times are median of 3 runs ``` Application benchmarks (YJIT enabled): ``` -------------- ----------- ---------- --------------- ---------- ------------------ ----------------- bench master (ms) stddev (%) experiment (ms) stddev (%) experiment 1st itr master/experiment activerecord 132.5 0.9 132.5 1.0 1.056 1.001 chunky-png 577.2 0.4 580.1 0.4 0.994 0.995 erubi-rails 902.9 0.2 894.3 0.2 1.040 1.010 hexapdf 1763.9 3.3 1760.6 3.7 1.027 1.002 liquid-c 56.9 0.6 56.7 1.4 1.004 1.003 liquid-compile 46.3 2.1 46.1 2.1 1.005 1.004 liquid-render 77.8 0.8 75.1 0.9 1.023 1.036 mail 114.7 0.4 113.0 1.4 1.054 1.015 psych-load 1635.4 1.4 1625.9 0.5 0.988 1.006 railsbench 1685.4 2.4 1650.1 2.0 0.989 1.021 rubocop 133.5 8.1 130.3 7.8 1.002 1.024 ruby-lsp 140.3 1.9 137.5 1.8 1.007 1.020 sequel 64.6 0.7 63.9 0.7 1.003 1.011 shipit 1196.2 4.3 1181.5 4.2 1.003 1.012 -------------- ----------- ---------- --------------- ---------- ------------------ ----------------- Legend: - master/experiment: ratio of master/experiment time. Higher is better for experiment. Above 1 represents a speedup. ``` ### Analysis The GC benchmarks show sweep time improvements of 13-39% across workloads, with the largest gains in hash-heavy and tree-based benchmarks where many simple embedded objects are allocated. The `hash1` benchmark shows nearly 40% faster sweeping, translating to 8.6% wall clock improvement. Application benchmarks show modest but consistent 1-2% improvements, with `railsbench` showing a 2.1% speedup. The improvement is smaller for applications because sweep time is typically a small fraction of total execution time, but the gains are additive with other optimizations. The `ring` benchmark shows a small regression in wall time despite faster sweeping, likely due to measurement noise or allocation pattern differences. The sweep improvement (+14.3%) is still present. The conservative nature of the fast path means some objects that could theoretically skip cleanup will still use the slow path. For example, a T_STRING with generic instance variables added via `instance_variable_set` will use the slow path even though the string content itself is embedded. This is intentional - We'd rather miss an optimisation opportunity than cause a memory leak. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 22 Jan '26

22 Jan '26

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

5 14

[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: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