Closed Bug 978647 Opened 7 years ago Closed 7 years ago

Firefox freezes and RAM consumption reaches 2-3 GB

Categories

(Core :: Audio/Video, defect)

28 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox27 --- unaffected
firefox28 + verified
firefox29 + verified
firefox30 + verified
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: alice0775, Assigned: cpearce)

References

Details

(4 keywords)

Attachments

(1 file)

Reported http://forums.mozillazine.org/viewtopic.php?p=13390013#p13390013

Steps To Reproduce:
1. Open http://whalesand23rds.wordpress.com/

Actual Results:
Firefox freezes and RAM consumption reaches 2-3 GB


Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/9ac7ed427cd2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131203142913
Bad:
http://hg.mozilla.org/mozilla-central/rev/8187818246ad
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131204003601
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9ac7ed427cd2&tochange=8187818246ad


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b96d513cd89f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131203164653
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/ccb5e249ab11
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131203164918
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b96d513cd89f&tochange=ccb5e249ab11

Triggered by:
  ccb5e249ab11	Chris Pearce — Bug 945947 - Re-enable DirectShow for MP3 playback on Vista and later. r=ajones We disabled MP3 playback on Windows using DirectShow as the duration was being incorrectly reported. While DirectShow was disabled, we supported MP3 playback via Windows Media Foundation, and we still used DirectShow on WinXP. Now that bug 918135 has landed the duration calculation has been fixed, so we can re-enable DirectShow for MP3 playback for all Windows versions. This enables us to avoid suffering from bug 882537 for MP3 on Windows.


Setting media.directshow.enabled = false helps.
Thanks for reporting this Alice!
Assignee: nobody → cpearce
OK, the problem here is the page is loading a zero length MP3 file in an <audio> element, and ParseMp3Headers() in DirectShowReader isn't detecting EOS properly (MediaResource::ReadAt() returning NS_OK and zero bytes read), so ParseMp3Headers() is getting stuck in a loop. 

We're also calling DispatchBytesConsumed in ChannelMediaResource::ReadAt() even if we've read 0 bytes. This instantiates a Runnable event, which is why we're crashing; we're allocating so many of these events that we're running out of memory.
Note: This crash affects Firefox 28, which is in beta and ships week of March 18.

The fix is pretty trivial, so we could get it uplifted.

Or, we could disable the DirectShow support in Firefox 28 (we will still get MP3 via the Windows Media Foundation backend, as we do in Firefox 27), and fix this in Firefox 29.
Assume if we reach EOS without deciding a stream is MP3, that the stream must not be MP3.

I will follow up with tests once they've run through Try and other platforms have been tested. In the meantime, let's get this landed.
Attachment #8384416 - Flags: review?(edwin)
Flags: in-testsuite?
Could you consider a quick uplift for 28 (and 29)? thanks
https://hg.mozilla.org/mozilla-central/rev/9401fbb063cb
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Comment on attachment 8384416 [details] [diff] [review]
Patch: handle EOS when looking for MP3 headers

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 945947, where we switched from using Windows Media Foundation to using DirectShow for MP3 decoding.
User impact if declined: Browser can be out-of-memory'd pretty easy.
Testing completed (on m-c, etc.): Tested locally. It landed on m-i yesterday.
Risk to taking this patch (and alternatives if risky): Risk is low. Alternative is to revert to using Windows Media Foundation for MP3 decoding, but this has reliability issues.
String or IDL/UUID changes made by this patch: None.
Attachment #8384416 - Flags: approval-mozilla-beta?
Attachment #8384416 - Flags: approval-mozilla-aurora?
Attachment #8384416 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Reproduced in nightly 2014-03-03.
The page works fine in nightly 30.0a1(2014-03-04), win 7 x64.
Status: RESOLVED → VERIFIED
Comment on attachment 8384416 [details] [diff] [review]
Patch: handle EOS when looking for MP3 headers

Let's get this into the last FF28 beta today.
Attachment #8384416 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Keywords: verifyme
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #14)
> https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/37e06d6ff4f8

FYI, this patch only affects code on Windows only. So B2G is unaffected. ;)
Verified as fixed using the following environment:

FF 28.0b9
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Build Id: 20140306171728
Os: Win 7 x 64

the bug is not reproducing anymore.
Verified fixed 29.0a2 (2014-03-10), win 7 x64
You need to log in before you can comment on or make changes to this bug.