New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 717528 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Calling disconnect() as well as stop() on an OscillatorNode causes it to leak memory and cpu (Pending Activity)

Reported by m...@wetsand.co.nz, May 2 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce the problem:
1. Create an AudioContext
2. Use context to create 1000 OscillatorNodes and call start
3.  Call stop on oscillators
4. Call disconnect on oscillators
5. run Dev Tools > Memory (or Profiles) > Take Heap Snapshot
6. view Containment > (Pending Activities group) > 1000 entries

What is the expected behavior?
The oscillator nodes should be garbage collected.

view Containment > (Pending Activities group) should show 0 entries

What went wrong?
The oscillator node were not collected and now taking up valuable cpu cycles and memory.

When run without the disconnect, the nodes are collected as expected.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 58.0.3029.81  Channel: stable
OS Version: OS X 10.11.6
Flash Version: 

This also happens when only disconnect (and not stop) is called on an oscillator. Probably oscillators should be cleaned up in this case also. 

Haven't tested if this applies to other nodes, but I think it also is the case with ConstantSourceNodes and possibly BufferSource.
 
oscillator-cleanup.js
593 bytes View Download

Comment 1 by m...@wetsand.co.nz, May 2 2017

Also tested in Canary (60.0.3087.0), same problem still applies!
Labels: TE-NeedsTriageHelp

Comment 3 by rtoy@chromium.org, May 4 2017

Status: Available (was: Unconfirmed)

Comment 4 by rtoy@chromium.org, May 4 2017

The issue is that because disconnect() is called right after stop(), the oscillator is disconnected from the destination, so any processing associated with stop() is never done.  This also includes not actually stopping the oscillator because it takes at least one render quantum to do that.  Since it was disconnected, that render quantum never happens.
Project Member

Comment 5 by sheriffbot@chromium.org, May 7 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: krajshree@chromium.org
 Issue 789035  has been merged into this issue.
 Issue 704041  has been merged into this issue.
Status: Available (was: Untriaged)
This problem still exists.  We do something for ABSNs for this kind of situation and we should consider doing the same for oscillators (and constant sources).

Sign in to add a comment