René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Infinite recursion between TriggerUncaughtException and InspectorConsoleCall when console.error throws","articleBody":"### Version\n\nv26.3.0 (also hit this on v22 macOS 15)\n\n### Platform\n\nDarwin 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\n\n### Subsystem\n\nV8 / Inspector / Process\n\n### What steps will reproduce the bug?\n\nHard to nail down to a single script — it's non-deterministic. But here's what triggers it:\n\nA 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.\n\nI caught it with `sample` while it was spinning at 94% CPU. Here's the stack:\n\n```\nuv_run → uv__io_poll → uv__async_io\n  → ThreadSafeFunction::AsyncCb\n    → CallbackScope::~CallbackScope\n      → InternalCallbackScope::Close\n        → v8::Function::Call\n          → Execution::Call → Invoke\n            → Isolate::ReportPendingMessages\n              → MessageHandler::ReportMessage\n                → TriggerUncaughtException\n                  → v8::Function::Call\n                    → Execution::Call → Invoke\n                      → Builtins_JSEntry\n                        → InspectorConsoleCall\n                          → v8::Function::Call  (← re-enters TriggerUncaughtException)\n```\n\nThe pattern is clear: `TriggerUncaughtException` reports via the inspector console, `InspectorConsoleCall` itself throws, and that throw goes right back into `TriggerUncaughtException`. Forever.\n\nYou'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:\n\n```js\nconst addon = require('bindings')('addon.node')\n// addon.startWorker(callbackThatThrows) while inspector is connected\n```\n\n### How often does it reproduce? Is there a required condition?\n\nNon-deterministic. Roughly 1 in 3 dev server restarts for me. Required conditions:\n\n- A native addon callback that throws\n- Inspector protocol active (dev tools or Node inspector)\n- Inspector connection has to be in a state where `InspectorConsoleCall` fails\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`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:\n\n- Fall back to writing to stderr directly (bypasses inspector entirely)\n- Or crash with `process.abort()` so at least it's obvious\n\nA `console.error` inside error handling should never be able to loop back into `TriggerUncaughtException`. That path should be guarded.\n\n### What do you see instead?\n\nThe 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.\n\n### Additional information\n\n- The workaround is replacing `console.error` with `process.stderr.write` in error handlers — it bypasses the inspector protocol breakage entirely\n- Same loop pattern reported in cdp-tools-mcp #74 (v0.4.3 patch)\n- This isn't specific to Next.js or Turbopack — any native addon with async callbacks can trigger it under the right conditions\n","author":{"url":"https://github.com/themuuln","@type":"Person","name":"themuuln"},"datePublished":"2026-07-06T15:30:22Z","url":"https://github.com/nodejs/node/issues/64326"}