Bisects to 1016e6257d240531feb3b211b5626c401926df4f ([d8] Run the message loop in the same RealmScope as the script).

Last time we had this issue it was because the wasm interpreter kept a (weak) global handle to the instance, and the instance kept the interpreter alive, hence we created a cycle and other weak handles were not released.
Maybe this is something similar.

CCing Ulan, who might be able to help finding the retaining path for this weak handle (the ICU object is stored in a weak global handle here: https://cs.chromium.org/chromium/src/v8/src/runtime/runtime-intl.cc?q=runtime-intl.cc&sq=package:chromium&dr&l=444).

This memory leak only exists because d8 is shutting down while a WebAssembly compilation is still running. If d8 waited for the compilation to complete, the memory would be deallocated correctly.

The problem seems to be that the WebAssembly compilation indirectly holds a reference to the Managed object of the "leaking" memory. Therefore the GC which runs when d8 shuts down does not deallocate the memory.

WebAssembly compilation is stopped when the isolate tears down, which happens after this final GC. A GC after the WebAssembly compilation would deallocate the memory, but since the isolate is torn down already at that point, we cannot run the GC anymore.

I reduce the priority because this memory leak is only an artifact of the d8 shutdown sequence.

We should still try to find out what actually keeps the ICU object alive (i.e. track the retaining path). Maybe we can use weak references or just reference less objects from the compilation job.

Here is a smaller repro.

Deleted: regress-801127.js 581 bytes

regress-801127.js 581 bytes View Download

ClusterFuzz testcase 5081530660814848 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.