927044 - crash in mozilla::AudioSegment::AppendAndConsumeChunk(mozilla::AudioChunk *)

Status: RESOLVED DUPLICATE of bug 941873

(Core :: Web Audio, defect, P1)

Description

[Gian-Carlo Pascutto [:gcp]]

This bug was filed from the Socorro interface and is 
report bp-b91205d2-31b6-4ab5-81b9-4c3332131015.
=============================================================

Happened some time after running:
http://webaudiodemos.appspot.com/input/index.html
So I guess that's likely the cause.

Superficially looks like an OOM crash from leaking/allowing the webpage to use all memory.

Comment 1

[(no longer active)]

Hmm, yeah this is an OOM crash indeed, but I can't reproduce.  How much memory do you have on your machine?

Comment 2

[Gian-Carlo Pascutto [:gcp]]

8G, you can see from the trace it happened when Firefox ran out of it's 4G address space.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

I can't reproduce it either, unfortunately this session had been alive for quite a while doing a load of things. That's the only audio related stuff that would hit that codepath that I remember, though.

Comment 4

[(no longer active)]

Well, in that case there is nothing that we can do here.  If you did not OOM here, you would have OOMed at the next allocation, somewhere random.  Web Audio is not necessarily to blame here.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

>Web Audio is not necessarily to blame here.

Well, the OOM happened because it was trying to allocate a 58M block. That's no peanuts. I think we have policy that such allocations should be fallible, see for example bug 862592.

Comment 6

[(no longer active)]

Oh yeah, you're right.  Sorry!

Comment 7

[Maire Reavy [:mreavy]]

Karl -- Could you look at this?  Thanks.

Comment 8

[Karl Tomlinson (:karlt)]

This is not simply about making the allocation fallible.
The array should not be getting that long, unless the Track AudioSegment has been backing up for minutes or hours without emptying.

Comment 9

[Karl Tomlinson (:karlt)]

The stack here matches that in bug 936784 comment 85.

Comment 10

[Karl Tomlinson (:karlt)]

Reopening because bug 936784 fixed only one case.

Comment 11

[Karl Tomlinson (:karlt)]

Attachment: testcase

STR:

1. Load testcase.
2. Press back button.
3. Watch memory use increase at about 1 kB/s.
4. Press forward button.
5. Press "Change Gain".
6. Notice delay in response, equal to time between 2 and 4.

The delay comes from chunks being buffered in the AudioDestinationNode's stream, because that stream is blocked but its inputs are not.

The ideal fix would be a fix for bug 941873, but, if that ends up risky, we could mute instead of suspend just to address the leak.

Comment 12

[Karl Tomlinson (:karlt)]

Will be fixed in bug 941873.