Similar to bug 1074387, I've found another instance where memory in webaudio seems to get double-counted. If I load up a song in The Infinite Jukebox (e.g. http://labs.echonest.com/Uploader/index.html?trid=TRDUQAQ14B46F9D0FF) and start playback, each time the playback position jumps to a different spot in the song, the memory reported for explicit/webaudio/audio-node/AudioBufferSourceNode/dom-nodes increases a bit, until it first causes heap-unclassified to turn negative and then finally exceeds the total amount reported for explicit memory. I've tested this with FF36.0.1 on Windows and FF36.0.2 and the current Nightly on Android.
Component: Video/Audio → Web Audio
I'll do a DMD run on this.
Assignee: nobody → erahm
Created attachment 8579599 [details] webaudio-dmd.txt.bz2 It looks like the |ThreadSharedFloatArrayBufferList| in |AudioBufferSourceNode| is being double counted.
Summary: Double-counting of memory in webaudio → Double-counting |ThreadSharedFloatArrayBufferList| in |AudioBufferSourceNode|
AudioBuffer and OscillatorNodeEngine may have the same issue. ConvolverNodeEngine and PeriodicWave guard on !mBuffer->IsShared() to prevent double counting. AudioBufferSourceNodeEngine does not seem to try to measure it. At least, that's at a lose audit of code that has a reference to this class.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The sizeof method for the buffer list could assert if IsShared is true maybe?
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.