Last Comment Bug 834667 - Firefox 17.0.2esr playing youtube video in html5 starts to leak serious amount of memory
: Firefox 17.0.2esr playing youtube video in html5 starts to leak serious amoun...
: regression
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: 17 Branch
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Matthew Gregan [:kinetik]
: Maire Reavy [:mreavy]
: 839493 (view as bug list)
Depends on: 792274
Blocks: 794426 851502
  Show dependency treegraph
Reported: 2013-01-25 05:03 PST by Zdenek Kraus
Modified: 2014-04-07 07:08 PDT (History)
14 users (show)
moz.mihaelav: in‑qa‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

log about:memory?verbose during leak on fresh profile (100.03 KB, text/plain)
2013-01-25 09:46 PST, Zdenek Kraus
no flags Details

Description Zdenek Kraus 2013-01-25 05:03:58 PST
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
2. open this video
3. skip onto 31:00
4. watch memory consumption grow very quickly

Actual results:

Firefox consume very large amount of memory, about 10GB in few seconds

Expected results:

no memory consumtion/leak, video continue playing.
Comment 1 Zdenek Kraus 2013-01-25 05:04:50 PST
I additionally found an SUSE forum, that discovered same issue
Comment 2 Zdenek Kraus 2013-01-25 07:15:55 PST
Reproduced successfully on Windows 7.
Comment 3 Loic 2013-01-25 07:34:31 PST
Could you try to reproduce the issue:

1) In safe mode:

2) With a new profile:

Same leak?
Comment 4 Zdenek Kraus 2013-01-25 08:03:40 PST
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.
Comment 5 Loic 2013-01-25 08:14:26 PST
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).
Comment 6 Zdenek Kraus 2013-01-25 09:46:04 PST
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.
Comment 7 Loic 2013-01-25 09:50:57 PST
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
Comment 8 Nicholas Nethercote [:njn] 2013-01-25 12:50:49 PST
That's bad!
Comment 9 Matthew Gregan [:kinetik] 2013-01-25 13:34:50 PST
Easily reproducible in 17.0.2esr, not reproducible in nightly, 18, or 17.0.1.  That narrows the regression range significantly.
Comment 10 Matthew Gregan [:kinetik] 2013-01-25 14:44:55 PST
2013-01-03-03-45-01-mozilla-esr17 GOOD
2013-01-06-03-45-05-mozilla-esr17 BAD

The only change to content/media in that range is bug 794426.
Comment 11 Matthew Gregan [:kinetik] 2013-01-30 03:52:36 PST
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.
Comment 12 Matthew Gregan [:kinetik] 2013-01-30 17:22:02 PST
And the final part of the puzzle is that 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.
Comment 13 Matthew Gregan [:kinetik] 2013-01-30 17:27:24 PST
Requesting esr17 approval for the patch in bug 792274.
Comment 14 Matthew Gregan [:kinetik] 2013-02-08 13:30:22 PST
Comment 15 Jan Horak 2013-02-11 00:24:32 PST
*** Bug 839493 has been marked as a duplicate of this bug. ***
Comment 16 bhavana bajaj [:bajaj] 2013-02-14 15:48:02 PST
Tracking esr for 19+ as the patch in 792274 is uplifted in Fx19 cycle targeting esr 17.0.3
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-03-06 14:57:02 PST
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.
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-03-06 14:57:50 PST
Dave, I'm wondering if we could have a Mozmill Endurance test created for this regression?
Comment 19 Zdenek Kraus 2013-03-06 21:52:58 PST
Antony, fix works great with 17.0.3, thanks
Comment 20 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-03-07 09:06:28 PST
(In reply to Zdenek Kraus from comment #19)
> Antony, fix works great with 17.0.3, thanks

Thanks Zdenek.
Comment 21 Dave Hunt (:davehunt) 2013-03-14 15:46:07 PDT
(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.
Comment 22 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-03-15 06:40:03 PDT
Thanks Dave, I've gone ahead and filed bug 851502 to develop the test.
Comment 23 Mihaela Velimiroviciu (:mihaelav) 2014-04-07 07:08:50 PDT
The automated test for this was tracked in bug 851502. Marking in-qa-testsuite+

Note You need to log in before you can comment on or make changes to this bug.