fenomas@ Thanks for the issue.

Request you to provide a sample file/URL where this issue can be reproduced, which will help in further triaging.
Also if tab crash is observed, request you to provide the Crash ID from chrome://crashes, which will help in investigating the issue.

Thanks..

Hi Susan, thanks for the reply.

The easiest way to reproduce this is to run the sample code above in the DevTools JS console. If you then check the Chrome task manager you can see the tab's memory usage spiral up until the tab crashes.

Alternately here's a jsfiddle with the same code: https://jsfiddle.net/4cL7ha6k/

I'm not sure about a crash ID; I have reporting enabled but this doesn't show up in chrome://crashes. It should be easy to reproduce locally though, I hope that's enough?

By the way, this reproduces for me on PC as well as mac. (tested on win10 64bit, Chrome 69.0.3497.100)

Thanks!
andy

Thank you for providing more feedback. Adding the requester to the cc list.

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

fenomas@

Can I ask if this is actual use case in your app?

So you're creating 20-seconds of audio buffer (memory allocated) and a thread every 20ms. If the machine is fast enough to finish the rendering task in ~10ms, then this might work nicely without a crash. Otherwise, I think it is bound to crash due to either out of memory or out of thread.

Hi Hongchan,

My issue here is the memory leak, not the crash. My actual app renders smaller buffers, and more slowly - but memory leaks on every render, so it still crashes eventually. The 20ms delay was just to make it easy to see.

Here's an alternate way of seeing the issue:

https://jsfiddle.net/3m1aw9co/

Each time you click the "render" button it renders a 10 minute buffer, so the memory footprint for the tab should increase by ~100MB. My issue is, that memory never gets released, even though there are no JS references to the rendered audio buffers.

Is there any way to tweak that code such that the rendered audio buffers get disposed? If so that would resolve my issue.

Thanks!

Thanks for the clarification. Yes, this is clearly a bug.

> Is there any way to tweak that code such that the rendered audio buffers get disposed? If so that would resolve my issue.

I am afraid there's no way to do that. I will investigate this further.

hongchan@

Understood, thanks very much for investigating! I hope this is fixable.

I've tried Memory and Performance tools in DevTool to trace the memory foot print, but obviously this issue is not being tracked correctly. So it is hard to tell what the real culprit is.

Will continue to investigate.

@Hongchan: I'm no expert but I think what you describe is true for all audio buffers. That is, when I call "context.createBuffer" on a regular audio context, the memory doesn't show up in DevTools memory or performance tabs, only in chrome's task manager. So I imagine audio buffers are stored somewhere internally, not managed by the JS VM, etc.

From browsing old bugs it looks like there have been a lot of issues in the past where audio buffer memory did not get released even though the JS object corresponding to that buffer had been cleaned up by the GC. I imagine that this issue here is the same sort of thing?