Issue metadata
Sign in to add a comment
|
ConvolverNode never releases memory after use
Reported by
bjorn.me...@gmail.com,
Apr 13 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.66 Safari/537.36 Example URL: https://jsfiddle.net/2eqq65mo/ Steps to reproduce the problem: 1. Create an AudioBuffer 2. Create a bunch of ConvolverNodes where you set the buffer, then set the buffer to null. 3. What is the expected behavior? Memory usage should stabilize. What went wrong? Memory usage grows beyond 10 GB and browser crashes. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? No Safari Technology Preview Chrome version: 50.0.2661.66 Channel: beta OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0 I would expect conv.buffer = null to release the memory. I would also expect garbage collection to release the ConvolverNodes since I do not even use them, especially if OS triggers some sort of memory pressure warning on Chrome. I cannot find a documented way on how to release such nodes, or how the lifecycle of OscillatorNodes might be different from say DelayNodes on one hand, or ABSN on the other hand. Maybe better documentation in the spec would be good? Also, when used in OfflineAudioContext, it seems the memory is never released either. This is probably related to the same root cause.
,
Apr 14 2016
FWIW, I can reproduce this on Canary 52.0.2702.2.
,
Apr 14 2016
Able to reproduce the issue and is regression broken in M35. Below are the bisect details for the same: Bisect Info: ============ 35.0.1866.0 - Bad build 35.0.1864.0 - Good build Change LOG: https://chromium.googlesource.com/chromium/src/+log/35.0.1864.0..35.0.1866.0?pretty=fuller&n=10000 Unable to provide narrow bisect as some of the chromium builds launched in between closes or crashes automatically before performing any operation. Tried manually and the same happens with the chromium builds. Also unable to reproduce the issue Windows or Linux. issues is a MAC specific issue. Removing Bisect label. Note: Memory increases upto 7GB and chrome crashes immediately. No crash reports are generated.
,
Apr 14 2016
Suspecting #254279 could be the possible suspect from the above CL. Review URL: https://codereview.chromium.org/156783003 Change URL: https://chromium.googlesource.com/chromium/src/+/0529271135bd65f8a357d668ba4882dcd48b973a @ dalecurtis: request you to please take a look into it. Please help us to reassign if not with respect to your change. Thanks.!
,
Apr 14 2016
WebAudio issue.
,
Apr 15 2016
Unfortunately, ConvolverNodes, DelayNodes, BiquadFilterNodes, and IIRFilterNodes don't currently get collected because they have a potentially long tail time where non-zero output occurs for zero inputs. To fix this, issue 357843 needs to be fixed by implementing tail processing so that we can stop these nodes when we know that all of the memory has been flushed out. The other issue with the buffer for the convolver apparently not being gc'ed is a problem which we will investigate. These should be released.
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 13 2016
This issue has been moved once and is lower than Pri-1. Removing the milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17 2016
,
Apr 24 2018
Reran the test case. Memory doesn't grow forever and actually stays bounded. We do however, run out of threads. Each convolver creates up to 3 threads to run the convolution fast enough. Maybe we should stop the threads when the buffer is set to null? |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Apr 13 2016