René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"v22.x: main thread self-deadlocks when creating a CpuProfiler under GC pressure — backport request for V8 a6eaf75741 (RecursiveMutex for Logger, crbug 41497149)","articleBody":"# v22.x backport request: V8 a6eaf75741 (\"[logging] Use RecursiveMutex for Logger\") — main-thread self-deadlock when a CpuProfiler is created\n\n### Version\n\nv22.20.0 (still present in v22.23.1 — see below)\n\n### Platform\n\n```text\nLinux 7.0.0-22-generic #22-Ubuntu SMP PREEMPT_DYNAMIC x86_64 (Docker node:22.20-bookworm-slim)\n```\n\n### Subsystem\n\ndeps/v8\n\n### What steps will reproduce the bug?\n\nCreate a `v8::CpuProfiler` (e.g. any native addon or embedder calling `v8::CpuProfiler::New`, or in-process profiling agents — we hit it through `@sentry/profiling-node`, whose N-API `Init` creates a profiler at `require()` time) in a process that already has a significant amount of compiled script code, at a moment when the heap is close to the incremental-marking trigger.\n\n`CpuProfiler::New` → `ProfilingScope` → `V8FileLogger::LogCompiledFunctions()` dispatches `CodeCreateEvent`s through the `Logger` dispatcher, which holds a **non-recursive** `base::Mutex` while calling listeners (`deps/v8/src/logging/code-events.h`). `ProfilerListener::CodeCreateEvent` initializes script line-ends, which **allocates**; if that allocation crosses the incremental-marking limit, V8 starts a major GC cycle on the same thread: `Heap::StartIncrementalMarking` → `MarkCompactCollector::StartCompaction` → `Isolate::AllowsCodeCompaction()` → `logger()->allows_code_compaction()` → attempts to re-acquire the same mutex → the main thread deadlocks against itself, forever.\n\nThis is Chromium bug 41497149, fixed upstream in May 2024 by V8 commit `a6eaf75741` (\"[logging] Use RecursiveMutex for Logger\", https://chromium-review.googlesource.com/c/v8/v8/+/5572952) — the commit message describes exactly this scenario. The fix landed in V8 ≥ 12.7, so Node 23/24 have it; Node 22's V8 12.4 does not, and the file is unchanged in v22.23.1 (`deps/v8/src/logging/code-events.h` still uses plain `base::MutexGuard`). Node 20/21 are equally affected but EOL.\n\nThe patch is minimal (one file, `Mutex` → `RecursiveMutex` in the `Logger` dispatcher) and V8 12.4 already ships `base::RecursiveMutex`, so it should float trivially onto `deps/v8` in v22.x.\n\n### How often does it reproduce? Is there a required condition?\n\nNon-deterministic by nature: the incremental-marking start has to land inside the `LogCompiledFunctions` walk. In production (NestJS monolith on a 2-vCPU host, addon loaded early in a large module graph, container cold-boot contention) we measured **roughly 1 process start in 3-4 freezing forever**. Calm restarts of the same build essentially never hit it, which makes it very painful to diagnose in the field.\n\n### What is the expected behavior?\n\nCreating a CPU profiler never deadlocks the process.\n\n### What do you see instead?\n\nThe process freezes before binding any port, with zero output and ~0 CPU, and never crashes (so process managers keep it \"online\"). gdb backtrace of the frozen main thread (all other threads idle — same-thread self-deadlock):\n\n```\n#1  pthread_mutex_lock\n#2  v8::internal::Isolate::AllowsCodeCompaction()\n#3  v8::internal::MarkCompactCollector::StartCompaction(...)\n#4  v8::internal::IncrementalMarking::StartMarkingMajor()\n#6  v8::internal::Heap::StartIncrementalMarking(...)\n#7  v8::internal::PagedSpaceAllocatorPolicy::EnsureAllocation(...)\n#8  v8::internal::MainAllocator::AllocateRawSlow(...)\n#11 v8::internal::FactoryBase\u003cv8::internal::Factory>::NewFixedArray(...)\n#12 v8::internal::String::CalculateLineEnds(...)\n#13 v8::internal::Script::InitLineEndsInternal(...)\n#14 v8::internal::Script::GetPositionInfo(...)\n#16 v8::internal::SourcePosition::InliningStack(...)\n#17 v8::internal::ProfilerListener::CodeCreateEvent(...)\n#18 v8::internal::ExistingCodeLogger::LogExistingFunction(...)\n#19 v8::internal::ExistingCodeLogger::LogCompiledFunctions(...)\n#20 v8::internal::ProfilingScope::ProfilingScope(...)\n#21 v8::internal::CpuProfiler::EnableLogging()\n#22 v8::internal::CpuProfiler::CpuProfiler(...)\n#23 v8::CpuProfiler::New(...)\n#24 Init(napi_env__*, napi_value__*)  (native addon, at require() time)\n#25 napi_module_register_by_symbol(...)\n#28 node::binding::DLOpen(...)\n```\n\nstrace shows the main thread parked in `FUTEX_WAIT_PRIVATE` on a contended mutex; every other thread is in its normal idle wait.\n\n### Additional information\n\nWorkarounds we validated/identified while root-causing this:\n- don't create profilers at startup (we made the Sentry profiling integration opt-in — also reported to Sentry: https://github.com/getsentry/sentry-javascript/issues/23178);\n- `--no-compact-code-space` sidesteps the re-entry (`AllowsCodeCompaction` short-circuits before touching the Logger mutex), at the cost of disabling code-space compaction;\n- upgrading to Node ≥ 23 removes the bug.\n\nNode 22 is in maintenance LTS until 2027-04 and this is a silent, unrecoverable hang, which is why a backport seems worth it despite maintenance mode.\n","author":{"url":"https://github.com/vincentventalon","@type":"Person","name":"vincentventalon"},"datePublished":"2026-08-08T15:16:31Z","url":"https://github.com/nodejs/node/issues/65140"}