Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using latest chrome version #71.0.3572.0. But unable to find the bisect results as the issue is inconsistent in nature. Hence, marking it as untriaged and requesting someone from Blink>JavaScript>WebAssembly team to help us in assigning it to the right owner.

reporter@ - Could you please let us know the chrome version in which the issue was reported.

Thanks...!!

I saw the  issue 2  days ago, but cannot remember the Canary version sorry...

Clemens, could this be related to Liftoff code not being collected? I don't know why that wouldn't have been a problem in M69, but is the closest thing that rings a bell to me based on the description.

We indeed changed a few things about how we track wasm reservations and allocations. Liftoff adds to that because it allocates more code.

IIRC, M-69 does not track code reservations via the WasmMemoryTracker, hence they don't add to the total amount of reserved address space. This was fixed since then, hence we are applying stricter limits now.
It might just be working as intended, but I will have to debug a bit more.

re #2: does it only reproduce on 32-bit, or also on 64-bit?

Failed to reproduce on Windows 10 in Canary 71.0.3578.0, both 32 and 64 bit.
What I tried was:

1. Go to https://faust.grame.fr/faustplayground/
2. In he "Load menu" click on "Big example" this load a bunch of WASM modules
3. Repeat step 2 several times (--> does not seem to do anything)


1. Go to https://faust.grame.fr/faustplayground/
2. In he "Load menu" click on "Big example" this load a bunch of WASM modules
3. Open a new tab, repeat steps 1 and 2
4. Repeat step 3 several times


1. Go to https://faust.grame.fr/faustplayground/
2. In he "Load menu" click on "Big example" this load a bunch of WASM modules
3. Click the garbage bin, confirm
4. Repeat steps 2 and 3 several times


Please provide precise reproduction steps and the version and architecture (32/64 bit) you used.

- Testing with Version 71.0.3578.0 on OS X El Capitan

- Go to https://faust.grame.fr/faustplayground/

- In he "Load menu" click on "Big example" this load a bunch of WASM modules

-  Repeat step 2 several times: after 6 times here, it start to produce " WebAssembly Instantiation: Out of memory: wasm memory" in the console

On a 64 bits machine : 2,2 GHz Intel Core i7

Cannot reproduce. Reproduction instructions from #8 are still unclear (what is step 2?).
Marking WontFix for now.

Sorry, let me explain again:

Testing with Version 71.0.3578.0 on OS X El Capitan, on a 64 bits machine : 2,2 GHz Intel Core i7

1) Go to https://faust.grame.fr/faustplayground/

2) In he "Load menu" click on "Big example" this load a bunch of WASM modules

3) Repeat step 2 several times: after 6 times here, it start to produce " WebAssembly Instantiation: Out of memory: wasm memory" in the console

Can you now reproduce the issue ? Still failing here with Version 72.0.3587.0.

- I cannot reproduce the problem in Firefox

- AFAICS the wasm memory allocated with "new WebAssembly.Memory" does not have to be explicitly deallocated right? It will be GCed when not more reference on it exists right?

Yes, I can reproduce this on Mac now.
I ran the page with some GC tracing flags enabled. At the time of the last GC, there are 37 WebAssembly memory buffers alive. Please check the attached log file for the retaining paths of all these memories.

If you need more output (e.g. the properties of the involved objects), I can also provide that.

Deleted: gc_log_wasm_memories 128 KB

gc_log_wasm_memories 128 KB View Download

1) I checked again that the modules are deleted in my JS code (so setting "null" to the JS variable that hold them right ?)

2) Yes I'm interested in getting "the properties of the involved objects"

3) I cannot reproduce the problem in Firefox Nightly or Safari (regular one)

4) I've just discovered I can also reproduce the problem on Chrome stable, but just doing more time the [In the "Load menu" click on "Big example" this load a bunch of WASM modules] step

In case it helps: the wasm module is actually generated from our Faust audio DSP compiler  (http://faust.grame.fr/about/), and the wasm memory is actually allocated inside the wasm module itself (I mean : we are not using JS WebAssembly.Memory() API in this use case)

You have to ensure that no reference to the wasm memories survives. Looking at the GC trace, it seems that "ScriptProcessorNode"s hold them alive, in their "HEAP" property. From codesearch, this seems to be related to webaudio: https://cs.chromium.org/search/?q=ScriptProcessorNode&sq=package:chromium&type=cs

Please check the attached log to find out where you are keeping references to these ScriptProcessorNodes, which then keep the memories alive.

Deleted: gc_log_wasm_memories_detailed 2.0 MB

gc_log_wasm_memories_detailed 2.0 MB View Download

Adding v8 memory sheriff to take a look at the traces.

I noticed that a lot of the retaining paths start in the JSFunction "getrequest.onreadystatechange". Maybe this is stale network requests that don't get cleaned up properly?

Maybe GC people have better tools or a better understanding to diagnose this further.

I reproduced the problem with a much simple example: a simple organ.hml page that does some wasm module + instance creation. The resulting object is not kept at all and should be GCed (see the moment at line 6164).

Agin the same page works correctly on Firefox and Safari.

Deleted: organ.html 297 KB

organ.html 297 KB View Download

Deleted: organ.wasm 7.3 KB

organ.wasm 7.3 KB Download

Anything new ? Can you reproduce the problem with te simple organ.htlm page ?

I checked the attachments in #20. Here, we are creating global handles to the wasm memories, because they are printed to the console. It's probably this code in organ.html:
5521     console.log(sp.HEAP);
5522     console.log(sp.HEAP32);
5523     console.log(sp.HEAPF32);

Additionally, you are printing the ScriptProcessorNode, which also keeps the instance and memory alive:
6164           faust.createorgan(audio_context, buffer_size, (node) => { console.log(node); });

After removing these statements, the ScriptProcessorNodes are still kept alive via "pending activities", which probably means that they still wait for audio input or something.
This can be seen by opening DevTools, selecting the memory tab and creating a heap snapshot (also thanks to Ulan for helping me here).

Adding WebAudio component.
I am wondering if there is some leak there. Should ScriptProcessorNodes die eventually? Or do they need to be disconnected explicitly?

That's helpful. Thanks clemensh@!

https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webaudio/script_processor_node.cc?sq=package:chromium&g=0&l=526

I think explicitly removing any handler for "onaudioprocess" event will help the situation. FWIW, ScriptProcessorNode is sort of special, so it will be alive even when the node is disconnected.

letz@ I wonder why this example uses ScriptProcessorNode? Do you have an example based on Audio Worklet?

"I think explicitly removing any handler for "onaudioprocess" ==> what do you mean? The current code does : sp.onaudioprocess = sp.compute;  (with sp = context.createScriptProcessor done before)


"letz@ I wonder why this example uses ScriptProcessorNode? Do you have an example based on Audio Worklet?" ==> the example with Audio Worklet had the same problem. So I tried to simplify the test code as much as possible, and it was easier to to that using SP.

letz@

I have not investigated the example code yet, but is this something possible?

```
sp.onaudioprocess = null
sp = null
```

Just to check, are you getting the same result from the latest Canary as well?

1) the SP node are created in a loop: the 'node' result is never kept:

for (var i = 0; i < 100; i++) {
        	faust.createorgan(audio_context, buffer_size, (node) => { console.log(node); });
        }

2) I added a "destroy" function that does sp.onaudioprocess = null

3) but the problems still remains in the latest Canary (even after removing console.log..etc...)