From: "nonster (Nony Dutton) via ruby-core" Date: 2026-01-22T08:15:41+00:00 Subject: [ruby-core:124605] [Ruby Bug#21716] YJIT panic: "all PendingBranchRefs should be unique" in net/http response reading (infinite unwind loop) Issue #21716 has been updated by nonster (Nony Dutton). alanwu (Alan Wu) wrote in #note-5: > Unfortunately, with the information available, there is not much we can do on our end. > > The PendingBranchRefs in question are transient reference counted objects in YJIT. They have clear > release points that should have been reached before the point of the panic. The loop in the > crash reporter is also odd, because it seems to be while traversing a singly linked list that > is only appended to in one spot in the addr2line.c. This is looking like some sort of heap/stack > corruption that is tripping over this point in the code. > > We changed the panic message to include the reference counts in 3.4.8, so that can show clearly > if a memory corruption took place. No hints as to who did the memory corruption at all, though. > It can be any native code in the process, including C extensions in the app. Sadly, we don't have much more information yet. We have one additional piece of the puzzle just in case it helps someone in the future. We're using `resque` along with `resque-pool` as our background job processor. We had been previously enabling `YJIT` with `RUBY_YJIT_ENABLE=true`. We changed it to lazily enable `YJIT` with: ```ruby Resque::Pool.after_prefork do |_job| RubyVM::YJIT.enable if defined?(RubyVM::YJIT) end ``` And we haven't seen the issue since (we used to see it about once a week). We'll try investigating what might be going wrong before the prefork that can lead to this. ---------------------------------------- Bug #21716: YJIT panic: "all PendingBranchRefs should be unique" in net/http response reading (infinite unwind loop) https://bugs.ruby-lang.org/issues/21716#change-116192 * Author: angelim@angelim.com.br (Alexandre Angelim) * Status: Feedback * Assignee: jit * 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 '' 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 ... ``` 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/