Emscripten Fetch API运行时动态下载资源内存泄漏问题求助

Hey there! Let's break down why you might be seeing persistent memory usage after using Emscripten's fetch API, especially since pure JavaScript works fine. Here are the most common pitfalls to check:

1. Did you forget to free Emscripten heap memory? #

This is the #1 culprit. Unlike pure JS where the garbage collector handles unused memory automatically, Emscripten's WASM heap is manually managed. If you allocated memory (using Module.allocate, _malloc, or similar methods) to store downloaded resources, you must explicitly free it with Module._free(pointer) once you're done with the data.

For example, if your C++ code compiled to WASM does something like:

void* buffer = malloc(data_size);
// copy downloaded data into buffer

You need to make sure you call free(buffer) when that buffer is no longer needed. If you pass the buffer to JS and forget to trigger this free, that's a guaranteed leak.

2. Are you holding onto lingering references? #

Double-check if your code (either in WASM or JS) keeps an unintended reference to the downloaded resource:

• A global JS variable that stores the fetched ArrayBuffer without being cleared
• A static variable on the WASM side that retains a pointer to the downloaded data
  Even if you free the heap, a leftover reference can prevent memory from being reclaimed properly.

3. Verify your fetch configuration #

Emscripten's fetch API has specific options that can affect memory handling. Make sure you're not using modes that implicitly retain memory:

• If you're using { mode: 'binary' } to load data directly into the WASM heap, confirm you're not leaving that allocation unused.
• Avoid unnecessary keepalive options, as they can prevent the browser from cleaning up fetch-related resources.

4. Use profiling to pinpoint the leak #

To get concrete data on where the memory is stuck:

• Enable memory growth in your Emscripten build with -s ALLOW_MEMORY_GROWTH=1
• Take heap snapshots in your browser's DevTools (Memory tab) before and after downloading resources. Compare the two to see if the leak lives in the WASM heap or JS heap.
• Use Module.getMemoryUsage() in your JS code to log heap usage before and after fetch operations—this will tell you if the WASM heap is growing uncontrollably.

Quick Test Fix #

If you suspect heap memory isn't being freed, modify your callback to explicitly free any allocated memory right after processing the data. For example:

fetch('/resource').then(response => response.arrayBuffer()).then(data => {
  const ptr = Module.allocate(new Uint8Array(data), 'i8', Module.ALLOC_NORMAL);
  // Process the data via WASM
  Module._free(ptr); // <-- Don't skip this line!
});

Chances are, the leak comes from not manually freeing WASM heap memory—this is the critical difference between pure JS (automatic GC) and Emscripten (manual heap management).

内容的提问来源于stack exchange，提问作者Sascha