2.3.0 deadlocks in Electron >= v40

[timfish]

Since the release of 2.3.0, Node profiling appears to deadlock in Electron v40/41/42.

Electron v40.10.0 - V8 14.4.258.32
Electron v41.5.2 - V8 14.6.202.34
Electron v42.0.2 - V8 14.8.178.14

Node.js v26 - V8 14.6.202.33

[timfish]

v2.3.0 Deadlock Analysis: Electron 40/41/42

Primary Suspect: Commit 8197ad0 – CPU Info Allocation Strategy Change

The Change

Before (v2.2.0):

class MeasurementsTicker {
private:
 uv_timer_t *timer;
 // ...
 uv_cpu_info_t cpu_stats; // PRE-ALLOCATED MEMBER
 // ...
};

void MeasurementsTicker::cpu_callback() {
 uv_cpu_info_t *cpu = &cpu_stats; // Use pre-allocated member
 int count;
 int err = uv_cpu_info(&cpu, &count); // Populates existing structure
 // ...
 uv_free_cpu_info(cpu, count);
}

After (v2.3.0):

class MeasurementsTicker {
private:
 uv_timer_t *timer;
 // ...
 // cpu_stats member REMOVED
 // ...
};

void MeasurementsTicker::cpu_callback() {
 uv_cpu_info_t *cpu = nullptr; // NOW: allocates fresh per callback
 int count;
 int err = uv_cpu_info(&cpu, &count); // ALLOCATES on EVERY tick
 // ...
 uv_free_cpu_info(cpu, count); // Must be called
}

Why This Is Risky in Electron 40/41/42

Execution Flow:

1. The uv_timer fires ticker every ~100ms, calling cpu_callback()
2. cpu_callback() now allocates memory via uv_cpu_info() on every invocation
3. In V8 14.4–14.8, profiler callbacks can trigger GC or memory pressure
4. If GC runs while uv_cpu_info() is allocating/freeing, the libuv event loop can stall

Deadlock Mechanism:

Timeline:
 [100ms] → uv_timer fires
 → ticker() calls cpu_callback()
 → cpu_callback() calls uv_cpu_info() [allocates memory]
 → Meanwhile, StopProfiling() on main isolate triggers GC
 → GC tries to acquire isolate lock
 → cpu_callback() waiting on memory allocation holds event loop
 → uv_cpu_info(&cpu, &count) stalls (libuv can't progress)
 → StopProfiling() tries to remove_cpu_listener()
 → remove_cpu_listener() tries to stop timer
 → Timer callback still running → DEADLOCK

Why Electron 40/41/42 Are Vulnerable:

• Electron runs the V8 isolate on the same thread as libuv
• V8 14.4–14.6 have more aggressive concurrent marking
• Concurrent marking can interfere with event loop callbacks mid-execution
• The continuous per-tick allocation (vs. one fixed member) increases contention on libuv's memory management
• Electron's IPC-heavy multi-context model increases GC pressure

Code Location

bindings/cpu_profiler.cc, lines 163–211:

void MeasurementsTicker::cpu_callback() {
 uv_cpu_info_t *cpu = nullptr; // ← SUSPECT: allocates on every tick
 int count;
 int err = uv_cpu_info(&cpu, &count);

 if (err) {
 return;
 }

 if (count < 1) {
 return;
 }

 uint64_t ts = uv_hrtime();
 uint64_t total = 0;
 uint64_t idle_total = 0;

 for (int i = 0; i < count; i++) {
 uv_cpu_info_t *core = cpu + i;
 // ... compute CPU stats
 }

 // ... invoke listeners
 
 uv_free_cpu_info(cpu, count); // ← REQUIRED cleanup
}

---

Secondary Suspect: Commit 5069626 – FreeAddonData Cleanup Order

The Change

Before (v2.2.0):

void FreeAddonData(napi_env env, void *data, void *hint) {
 Profiler *profiler = static_cast<Profiler *>(data);

 if (profiler == nullptr) {
 return;
 }

 if (!profiler->active_profiles.empty()) {
 for (auto &profile : profiler->active_profiles) {
 CleanupSentryProfile(profiler, profile.second, profile.first);
 // ↑ UNDEFINED BEHAVIOR: erases from map while iterating!
 }
 }
 // ...
}

After (v2.3.0):

void FreeAddonData(napi_env env, void *data, void *hint) {
 Profiler *profiler = static_cast<Profiler *>(data);

 if (profiler == nullptr) {
 return;
 }

 for (auto &profile : profiler->active_profiles) {
 if (profile.second != nullptr) {
 profile.second->Stop(profiler);
 delete profile.second;
 }
 }
 profiler->active_profiles.clear();
 // ...
}

Why This May Still Deadlock

The new cleanup path calls Stop() on each profile:

v8::CpuProfile *SentryProfile::Stop(Profiler *profiler) {
 if (status != ProfileStatus::kStarted) {
 return nullptr;
 }

 v8::CpuProfile *profile = profiler->cpu_profiler->StopProfiling(...);

 // Remove the memory sampler
 profiler->measurements_ticker.remove_heap_listener(id, memory_sampler_cb);
 profiler->measurements_ticker.remove_cpu_listener(id, cpu_sampler_cb);
 
 status = ProfileStatus::kStopped;
 return profile;
}

Race Condition:

During addon unload/GC, if the timer callback is still active:

1. remove_heap_listener() and remove_cpu_listener() erase from their maps
2. Meanwhile, ticker() callback may be executing, reading from those maps
3. Iterator invalidation → use-after-free or lock contention
4. In Electron's multi-context IPC environment, this race is likely to manifest

References

• libuv cpu_info documentation
• V8 concurrent marking (14.4–14.8)
• Electron threading model