969826 - Runaway memory use from playing sound on Windows

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

This site is causing some sort of runaway memory consumption:

http://www.saturn.de/webapp/wcs/stores/servlet/MultiChannelShowMediaPlayer?storeId=48352&catEntryId=254717&langId=-3&track=0&mediaType=audio

Tested on a new Profile, win7 x64 using today's Nightly build:
cset: https://hg.mozilla.org/mozilla-central/rev/cafe909f7e07 win32 m-c build

Open site in a fresh Profile
Site plays ~10-15 secs of music, the stops

Watching with Windows taskmanager the CPU & Memory use is climbing 
Closing the Tab will NOT stop the memory consumption
Closing the Browser will NOT stop the memory consumption

Memory use will climb till its OOM/Exhausted and the browser crashes.

Crash reports from Mozillazine users:
https://crash-stats.mozilla.com/report/index/5d00ed45-bf09-4d38-b65f-9a24e2140208
https://crash-stats.mozilla.com/report/index/afe66b09-61a0-4408-ba98-63d342140208

Reportedly does not crash on Linux.

Not sure if this is a regression.  Does not exhibit this behavior in latest Chrome dev or IE 11

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Further, reports show that site does not crash in Firefox 28, or 29.

Comment 2

[Gary [:streetwolf52]]

Confirmed on Windows 8.1 x64.

Comment 3

[Tom S [:evilpie]]

Looking at the crash stack, this is most likely caused by Bug 960873. Nothing really points to the JS engine.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Unfortunately I am away from my windows machine for the next week.  I suggest trying to backout Part 6 from bug 960873 to see if it fixes the problem:

  https://hg.mozilla.org/mozilla-central/rev/66b4798ac58f

If that works, then I suggest just landing the back out for now.  We can then open a new bug, or change this bug, for me to re-land a fixed DirectShow with audio compaction.

At this point its unclear to me if this is a bug in the DirectShowCopy functor (most likely), a corner case caused by a non-MP3 format, or a difference in how malloc_good_size works on windows.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

I was able to verify its definitely serving mp3 files.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

And on mac this website only uses ~100kb of decoded audio.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can someone make comment 4 happen?

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Attachment: bug969826_fix_directshow.patch

Can someone with a working windows build test this patch?

From visual inspection it appears I am not tracking the number of previously copied bytes correctly in DirectShowCopy.  This could result in returning a number of frames copied larger than expected by the AudioCompactor.  This can then cause |aFrames -= framesCopied| to wrap around.

A debug build should also catch this with the assertion here:

  https://hg.mozilla.org/mozilla-central/rev/41ddd2fd2031#l2.53

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Lets land this patch as its clearly an issue, but leave the bug open until someone can verify that it fixes the issue discussed here.

Incidentally, I think this only would have been triggered if compaction required 2+ allocations and the final allocation included some small amount of slop.  There also should have been audio defects if 3+ allocations were needed for compaction.  The mp3 file I tested against must not have triggered these conditions.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/27b73e8b6446

Comment 11

[Jim Jeffery not reading bug-mail 1/2/11]

Just tested this patch from cset: https://hg.mozilla.org/integration/mozilla-inbound/rev/27b73e8b6446 on Win7 x64 and the crash, and high-memory use is fixed. 

I'm not all that experienced on how mp3's play on my system, and I rarely do that in the browser, but there seems to be a lot of CPU during playback 25-30% on a quad-core Athlon Phenom II., which if I understand correctly is a full-core + 

IE11 does not use but 8% CPU on the same page.

That being said, it could be my system, or another bug, but this bug appears fixed from the run-away memory and crash.

Comment 12

[Andrew McCreight [:mccr8]]

Thanks for confirming the fix!

I guess this doesn't need to be backported, because it is only on 30 and two B2G branches, and it is a Windows-only problem?

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Jim, thanks for testing!

Is that CPU just for an MP3 you opened as a file, or is that the CPU using that website in comment 0?

On my v1.3 b2g buri device I get ~35% CPU for a local file and ~90% for that website.

Also, I would not be surprised if those copy loops on windows are not very efficient.  That should match what we were doing before.  Chris, do you know if we've seen high CPU usage from mp3 on windows in the past?

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Andrew McCreight [:mccr8] from comment #12)
> I guess this doesn't need to be backported, because it is only on 30 and two
> B2G branches, and it is a Windows-only problem?

Correct.  It only effected windows which was not uplifted.

Comment 15

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/27b73e8b6446

Comment 16

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Ben Kelly [:bkelly] from comment #13)
> Jim, thanks for testing!
> 
> Is that CPU just for an MP3 you opened as a file, or is that the CPU using
> that website in comment 0?
> 
> On my v1.3 b2g buri device I get ~35% CPU for a local file and ~90% for that
> website.
> 
> Also, I would not be surprised if those copy loops on windows are not very
> efficient.  That should match what we were doing before.  Chris, do you know
> if we've seen high CPU usage from mp3 on windows in the past?

That high CPU was just on the link in comment #0, the Mia Link for the sound bites.

Thanks for the quick fix.

Comment 18

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, the Issue happened on http://areweplayingyet.org/ too.

bp-c328e161-73ca-4bac-a12c-771e02140210
bp-d3401f33-a10f-4043-b498-513df2140210

today's nightly fixed the crashes.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140210030201 CSet: ecf20a2484b6