WebAssembly Memory Leak Triage Runbook Builder

Create a WebAssembly memory leak triage runbook for browser or server runtimes with heap growth, linear memory snapshots, bindings, allocators, and release validation.

Prompt Template

You are a senior runtime performance engineer. Build a triage runbook for suspected WebAssembly memory leaks.

Application context: [browser app, Node service, edge runtime, plugin, game engine, data processing tool]
WASM source language: [Rust, C/C++, AssemblyScript, Go, Zig, other]
Runtime and glue code: [wasm-bindgen, Emscripten, wasm-pack, Wasmtime, Wasmer, custom loader]
Symptoms: [linear memory grows, tab crashes, worker OOM, stale objects, slow GC, repeated instantiation, mobile-only failure]
Workload pattern: [file parsing, image processing, simulation loop, crypto, ML inference, audio, long-lived session]
Memory ownership boundaries: [JS objects, typed arrays, exported pointers, callbacks, closures, handles, finalizers]
Allocator details: [wee_alloc, dlmalloc, system allocator, custom arena, unknown]
Profiling tools available: [Chrome DevTools, Firefox Profiler, heap snapshots, wasm tools, logs, metrics, CI replay]
Reproduction inputs: [sample file, user session, benchmark script, synthetic loop, production trace]
Constraints: [no private data in traces, mobile memory ceiling, real-time performance, release deadline]
Recent changes: [dependency update, binding change, worker refactor, streaming compile, new cache, feature flag]

Create:
1. Reproduction plan that isolates browser, server, worker, and input-size variables.
2. Evidence checklist for linear memory growth, JS heap retention, object URL leaks, repeated instances, and unfreed native allocations.
3. Profiling workflow for DevTools, heap snapshots, allocation timeline, runtime logs, and benchmark loops.
4. Boundary audit for pointers, buffers, closures, callbacks, finalizers, and ownership transfer.
5. Source-language checklist for Rust, C/C++, AssemblyScript, and Go leak patterns.
6. Fix decision tree with allocator, lifecycle, pooling, teardown, worker restart, and API redesign options.
7. Regression test strategy with memory budgets and repeat-run thresholds.
8. Observability plan for production-safe memory metrics and crash signals.
9. Release checklist for browser compatibility, mobile devices, and rollback criteria.
10. Escalation packet for runtime, frontend, backend, and QA owners.

Do not invent profiler output or unsafe compiler flags. Mark runtime-specific commands as examples to verify in the target toolchain.

Example Output

Triage Path

1. Reproduce with a fixed input in a loop for 100 iterations.

2. Track JS heap, WASM linear memory size, active module instances, and worker count after each iteration.

3. If JS heap grows while linear memory stays flat, inspect retained typed arrays, object URLs, callbacks, and closures.

4. If linear memory grows but JS heap is stable, audit native allocations, exported free calls, allocator behavior, and arena reset points.

Evidence Table

| Signal | Likely Area | Next Check |

|---|---|---|

| New WebAssembly.Memory per job | Loader lifecycle | Instance reuse or teardown |

| ArrayBuffer retained in heap snapshot | JS glue code | Typed array references and object URLs |

| Memory grows only after errors | Cleanup path | finally blocks and exported free calls |

Regression Guard

Run the benchmark before and after the fix and fail CI when retained memory exceeds the agreed budget after warm-up.

Tips for Best Results

  • 💡Separate JS heap growth from WASM linear memory growth before choosing a fix.
  • 💡Ask for the source language and binding layer because leak patterns differ sharply across toolchains.
  • 💡Use repeatable workloads; one-off manual profiling rarely proves a WebAssembly leak is fixed.