Infinite recursion between TriggerUncaughtException and InspectorConsoleCall when console.error throws

[themuuln]

Version

v26.3.0 (also hit this on v22 macOS 15)

Platform

Darwin TS-Temuulen-2.local 25.5.0 Darwin Kernel Version 25.5.0: Fri Jun 5 02:15:17 PDT 2026; root:xnu-11471.122.99.501.2~1/RELEASE_ARM64_T6000 arm64 arm

Subsystem

V8 / Inspector / Process

What steps will reproduce the bug?

Hard to nail down to a single script — it's non-deterministic. But here's what triggers it:

A native addon (in my case Turbopack via napi-rs ThreadSafeFunction) calls a JS callback that has a pending exception. Instead of handling the error normally, the process locks up.

I caught it with sample while it was spinning at 94% CPU. Here's the stack:

uv_run → uv__io_poll → uv__async_io
  → ThreadSafeFunction::AsyncCb
    → CallbackScope::~CallbackScope
      → InternalCallbackScope::Close
        → v8::Function::Call
          → Execution::Call → Invoke
            → Isolate::ReportPendingMessages
              → MessageHandler::ReportMessage
                → TriggerUncaughtException
                  → v8::Function::Call
                    → Execution::Call → Invoke
                      → Builtins_JSEntry
                        → InspectorConsoleCall
                          → v8::Function::Call  (← re-enters TriggerUncaughtException)

The pattern is clear: TriggerUncaughtException reports via the inspector console, InspectorConsoleCall itself throws, and that throw goes right back into TriggerUncaughtException. Forever.

You'd probably need a napi-rs addon with a ThreadSafeFunction that calls into JS and throws, with the inspector/profiler attached during the call. Something like:

const addon = require('bindings')('addon.node')
// addon.startWorker(callbackThatThrows) while inspector is connected

How often does it reproduce? Is there a required condition?

Non-deterministic. Roughly 1 in 3 dev server restarts for me. Required conditions:

• A native addon callback that throws
• Inspector protocol active (dev tools or Node inspector)
• Inspector connection has to be in a state where InspectorConsoleCall fails

What is the expected behavior? Why is that the expected behavior?

TriggerUncaughtException should not be re-entrant through the inspector. If the inspector console itself throws during error reporting, Node should detect the re-entrance and either:

• Fall back to writing to stderr directly (bypasses inspector entirely)
• Or crash with process.abort() so at least it's obvious

A console.error inside error handling should never be able to loop back into TriggerUncaughtException. That path should be guarded.

What do you see instead?

The process pegs a CPU core at 94-100%. RSS starts around 150MB and grows to 2.2GB+ — keeps allocating because V8's exception machinery keeps running. The machine starts swapping. kill (SIGTERM) does nothing, have to kill -9 it. Meanwhile the entire system slows to a crawl from memory pressure.

Additional information

• The workaround is replacing console.error with process.stderr.write in error handlers — it bypasses the inspector protocol breakage entirely
• Same loop pattern reported in cdp-tools-mcp may be it's good idea go tell something about this fork? #74 (v0.4.3 patch)
• This isn't specific to Next.js or Turbopack — any native addon with async callbacks can trigger it under the right conditions

[Mahnoor-Zaffar]

Hey, I'd love to grab this issue. The recursion loop makes complete sense; I need to add a thread-local re-entrancy guard inside TriggerUncaughtException to catch if the inspector throws again, and bail out to a process abort or direct stderr write instead of spinning forever.

Could you assign this to me? Thanks!

[joharikapil31-ops]

Thank you, please assign this issues. Johari Kapil Ahmad Azhari Bin Johari Asko

…

On Tue, 7 Jul 2026, 05:43 Mahnoor Zaffar, ***@***.***> wrote: *Mahnoor-Zaffar* left a comment (nodejs/node#64326) <#64326 (comment)> Hey, I'd love to grab this issue. The recursion loop makes complete sense; I need to add a thread-local re-entrancy guard inside TriggerUncaughtException to catch if the inspector throws again, and bail out to a process abort or direct stderr write instead of spinning forever. Could you assign this to me? Thanks! — Reply to this email directly, view it on GitHub <#64326?email_source=notifications&email_token=BZCGXPJS7AHGGP5P34L5VJL5DQMQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZG44DKOBXGA4KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4897858708>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BZCGXPPIUNN6OET4IRKJTAT5DQMQDAVCNFSNUABEKJSXA33TNF2G64TZHMZDOMJZGM3TOOJ3JFZXG5LFHM2DQMRQGYZDQMJYG2QXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BZCGXPPHGDBPS5JJ4O2Y3Q35DQMQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZG44DKOBXGA4KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BZCGXPKYYBMHSGR73TYXG6T5DQMQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZG44DKOBXGA4KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[themuuln]

Fixed in #64327, already approved. Hold off on this one.