User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130125094555
Steps to reproduce:
1. enable HTML5 on http://youtube.com/html5
2. open this video https://www.youtube.com/watch?v=jTMxKUYrgJ4
3. skip onto 31:00
4. watch memory consumption grow very quickly
Firefox consume very large amount of memory, about 10GB in few seconds
no memory consumtion/leak, video continue playing.
I additionally found an SUSE forum, that discovered same issue http://forums.opensuse.org/english/get-technical-help-here/applications/482276-serious-memory-leak-firefox-17-0-2esr.html
Reproduced successfully on Windows 7.
Could you try to reproduce the issue:
1) In safe mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
2) With a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
In both cases (safe mode, new profile) it still leaking, also with new profile and safe mode.
Additionally on windows 7 after firefox consumed about 3GB of memory, it crashed. On gentoo it continues to cosume memory and forcing system to swap, without ulimits. With ulimits it just crashed with segmentation fault.
Thanks. Could you type about:memory?verbose during the leak and copy/paste the memory log here (just reuse the fresh profile with only one tab displaying the YT html5 video).
Created attachment 706450 [details]
log about:memory?verbose during leak on fresh profile
It's about 3 seconds before crash. Only YT and about:memory tabs open.
1,976,995,531 B (100.0%) -- explicit
├──1,892,440,576 B (95.72%) -- media
│ ├──1,892,436,480 B (95.72%) ── decoded-video
│ └──────────4,096 B (00.00%) ── decoded-audio
Easily reproducible in 17.0.2esr, not reproducible in nightly, 18, or 17.0.1. That narrows the regression range significantly.
The only change to content/media in that range is bug 794426.
I've confirmed that this is a regression from bug 794426 by testing that changeset and its parent.
This is fixed (or at least hidden) by Paul's fix in bug 792274.
What happens is: after seeking, RecreateDecodedStream is called, causing the decoder to gain a DecodedStream it did not previously have (this is what's is fixed by Paul's patch). That stream causes HaveEnoughDecodedVideo to perpetually return false because stream->mStream->HaveEnoughBuffered(TRACK_VIDEO) always returns false. This causes the decoder's video queue to grow without bound, resulting in rapid memory consumption.
Before the patch in bug 794426, stream->mStream->HaveEnoughBuffered(TRACK_VIDEO) alternates between true and false. The video queue grows above AMPLE_VIDEO_FRAMES, but not without bound.
And the final part of the puzzle is that https://hg.mozilla.org/releases/mozilla-esr17/rev/15b8772620ec#l1.24 from 794426 causes SendStreamData to bail early when there's an audio thread, which there is when we're playing back normally. The DecodedStream is set up after seeking via RecreateDecodedStream but isn't fed any data after playback resumes (which recreates the audio thread), leaving the DecodeStream in a perpetually starved state, causing HaveEnoughDecodedVideo to return false.
Requesting esr17 approval for the patch in bug 792274.
*** Bug 839493 has been marked as a duplicate of this bug. ***
Tracking esr for 19+ as the patch in 792274 is uplifted in Fx19 cycle targeting esr 17.0.3
Sorry bajaj for missing this verification. I just confirmed this does not reproduce for me with the latest 17esr. Zdenek, please reopen this bug if you can still reproduce.
Dave, I'm wondering if we could have a Mozmill Endurance test created for this regression?
Antony, fix works great with 17.0.3, thanks
(In reply to Zdenek Kraus from comment #19)
> Antony, fix works great with 17.0.3, thanks
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #18)
> Dave, I'm wondering if we could have a Mozmill Endurance test created for
> this regression?
If we can reduce the test case down and use a video served from localhost then that sounds good to me. We already have tests for playing flash video content.
Thanks Dave, I've gone ahead and filed bug 851502 to develop the test.
The automated test for this was tracked in bug 851502. Marking in-qa-testsuite+