Debugging V8FatalErrorCallback OOM Crashes in Electron Live Streaming Client

This article describes the investigation and resolution of V8FatalErrorCallback out‑of‑memory (OOM) crashes in a PC Taobao Live streaming client built with Electron.

Crash Stack Analysis

The initial stack trace shows that the V8 old‑generation heap runs out of memory during garbage collection, triggering the V8FatalErrorCallback.

Compilation Cache Issue

Electron’s v8‑compile‑cache stores compiled scripts in a cache that is only cleared during a full GC ( CollectAllAvailableGarbage ). Because the cache is not reclaimed regularly, memory usage continuously grows, eventually causing OOM.

Solution attempts:

Disable the cache by launching the app with --no-compilation-cache and removing the require('v8-compile-cache') import.

Increase the V8 semi‑space size from the default 16 MiB to 64 MiB using the flag --max-semi-space-size=64 .

Raise the old‑generation heap limit with --max-old-space-size=8192 .

These changes reduced OOM frequency but did not eliminate it.

V8 Heap Limit Investigation

V8’s heap limit is calculated as 3 * max_semi_space_size + max_old_generation_size . The default values are 16 MiB (or 8 MiB on 32‑bit) for the semi‑space and 1400 MiB (or 700 MiB) for the old generation, yielding a 4.5 GiB limit on 64‑bit systems. The actual limit can be larger (e.g., 4 GiB) depending on physical memory and internal heuristics.

Key source files examined:

src/third_party/electron_node/deps/v8/include/v8.h – defines heap_size_limit() .

src/third_party/electron_node/deps/v8/src/heap/heap.cc – implements MaxReserved() and ConfigureHeap() where the limits are set.

Disabling Pointer Compression

Starting with V8 9.2, pointer compression reduces pointer size to 32 bits, limiting the heap to 4 GiB. To raise the limit, pointer compression is disabled by setting the GN variables v8_enable_pointer_compression = false and v8_enable_pointer_compression_shared_cage = false in src/electron/build/args/all.gn and in src/third_party/electron_node/deps/v8/BUILD.gn . After rebuilding Electron with these flags, the heap limit expands to 8 GiB on 64‑bit systems.

v8_enable_pointer_compression = false
v8_enable_pointer_compression_shared_cage = false

Building Electron from Source

The article provides a step‑by‑step guide for Windows:

Install Visual Studio 2019, Node.js, Python 3, Git, and the Windows 10 SDK.

Configure environment variables for depot_tools , proxy settings, and CHROMIUM_BUILDTOOLS_PATH .

Sync the source with gclient sync and generate build files with gn gen out/Release (or out/Testing for debugging).

Compile using ninja -C out/Release electron -j 4 .

Common build errors (missing SDK components, undefined identifiers, etc.) are documented with their fixes.

Memory Leak Diagnosis with Chrome DevTools

Even after increasing the heap, the application still suffered from memory leaks. Using Chrome DevTools:

Take two heap snapshots (e.g., 1 minute apart) and compare them to identify growing object types such as String and Array .

Use the Performance panel with the “Memory” checkbox to record JS heap usage over time, revealing a steady increase.

The leak was traced to the electron-log onError handler, which repeatedly logged failed ARM (arms) network requests, creating many error objects.

import TraceSdk from '@ali/trace-sdk-node'
import log from 'electron-log'

let trace = TraceSdk()
const sendErrorLog = trace.logError

log.catchErrors({
  onError(error) {
    // Filter arms fetch errors
    if (!error?.message.includes('https://s-gm.mmstat.com/arms')) {
      sendErrorLog(error)
    }
  },
})

Filtering the ARM error prevents the recursive logging and eliminates the leak.

Runtime Heap Monitoring

For production monitoring, the article suggests:

Periodically call v8.getHeapStatistics() and report metrics (total heap size, used size, limit) to a monitoring platform.

Use the node‑memwatch package to listen for stats (GC events) and leak events, and generate HeapDiff snapshots when a leak is detected.

{
  "num_full_gc": 1,
  "num_inc_gc": 1,
  "heap_compactions": 1,
  "usage_trend": 0,
  "estimated_base": 5350136,
  "current_base": 5350136,
  "min": 0,
  "max": 0
}

When a leak is reported, HeapDiff shows the object types responsible, enabling targeted fixes.

Conclusion

The investigation started from a V8FatalErrorCallback stack trace, explored configuration tweaks, examined V8 source code, rebuilt Electron with pointer compression disabled, and finally used DevTools Memory and Performance panels to locate a JavaScript‑level memory leak caused by unfiltered error logging. Runtime monitoring with v8.getHeapStatistics and node‑memwatch provides ongoing protection against similar OOM issues.