1144358 - Double-counting |ThreadSharedFloatArrayBufferList| in |AudioBufferSourceNode|

Status: NEW

(Core :: Web Audio, defect, P4)

Description

[Jan Henning [:JanH]]

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.

Comment 1

[Eric Rahm [:erahm]]

I'll do a DMD run on this.

Comment 2

[Eric Rahm [:erahm]]

Attachment: webaudio-dmd.txt.bz2

It looks like the |ThreadSharedFloatArrayBufferList| in |AudioBufferSourceNode| is being double counted.

Comment 3

[Andrew McCreight [:mccr8]]

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.

Comment 4

[Andrew McCreight [:mccr8]]

The sizeof method for the buffer list could assert if IsShared is true maybe?

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.