Thank you for reporting the problem to us.

Do you have reproducible files? It helps us to understand the problem better if we can reproduce.

I suspect the same root cause as https://bugs.chromium.org/p/chromium/issues/detail?id=339480.

I suspect the reason it only appears in a worker is that there are less other things going on in the worker that would trigger v8 garbage collection.

See the attached files to reproduce the problem.

Deleted: WebSocket.js 134 bytes

WebSocket.js 134 bytes View Download

Deleted: Worker.html 158 bytes

Worker.html 158 bytes View Download

Deleted: server.js 693 bytes

server.js 693 bytes View Download

Thank you for providing more feedback. Adding requester "kojii@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#4: Thank you for the repro, handing this to the team for further investigations.

Requesting someone from the respective team to take a look and help in further investigation

The NextAction date has arrived: 2017-09-19

I reproduced with the supplied scripts on version 63.0.3223.8. However, when I removed the call to console.log from WebSocket.js the leak went away. This makes sense, as console.log() requires the browser to keep a reference to the data.

Is there a way to reproduce this without console.log()?

I reproduced the problem with Chrome 60 without console.log(). You need to wait.
Memory increase more and more after each garbaging.

Thank you for providing more feedback. Adding requester "ricea@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#11 Thanks for the update. I am trying to reproduce, without much success so far, but I will leave it going over the weekend.

I left this running over the weekend with no noticeable memory leak. Chrome version 63.0.3230.0.

I did initially have a problem with a memory leak on the server side, which I resolved by porting it to use the "ws" module. This was maybe an issue with my version of nodejs, as the memory leak was severe enough to use all memory in a few minutes.

I've attached my modified server.js. I've also attached WebSocket.js, although the only change is to remove the console.log statement.

Deleted: server.js 547 bytes

server.js 547 bytes View Download

Deleted: WebSocket.js 111 bytes

WebSocket.js 111 bytes View Download

I tried an alternative where the Worker sends the size of the received data back to the page and the page sums it. This time I ran it on 63.0.3227.0 overnight with LeakSanitizer enabled. There was an unrelated 2MB leak the nvidia drivers, and an unrelated 4KB leak caused by an issue with thread shutdown.

After the page loads there is a gradual increase in memory consumption in both the browser process and the render process. After a few hours this reaches a steady state and doesn't increase further.

The peak memory usage is about 300MB more than the initial memory usage. My hypothesis is that this is mostly due to memory fragmentation, and unavoidable given the amount of data in flight.

The NextAction date has arrived: 2017-10-31

Effectively, I can't reproduce with Chromium 62 but I have a question if i send the data to the main thread with a postMessage when this data will be free from the memory if the worker stay alive ?

As long as the Worker no longer references the data, it can be collected as normal while the worker is still alive.