834667 - Firefox 17.0.2esr playing youtube video in html5 starts to leak serious amount of memory

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Zdenek Kraus]

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


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]

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

Comment 2

[Zdenek Kraus]

Reproduced successfully on Windows 7.

Comment 3

[Loic]

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

Same leak?

Comment 4

[Zdenek Kraus]

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]

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]

Attachment: 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]

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 [inactive]]

That's bad!

Comment 9

[Matthew Gregan [:kinetik]]

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-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]]

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]]

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.

Comment 13

[Matthew Gregan [:kinetik]]

Requesting esr17 approval for the patch in bug 792274.

Comment 14

[Matthew Gregan [:kinetik]]

https://hg.mozilla.org/releases/mozilla-esr17/rev/7606a3baed96

Comment 16

[bhavana bajaj [:bajaj]]

Tracking esr for 19+ as the patch in 792274 is uplifted in Fx19 cycle targeting esr 17.0.3

Comment 17

[u279076]

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

[u279076]

Dave, I'm wondering if we could have a Mozmill Endurance test created for this regression?

Comment 19

[Zdenek Kraus]

Antony, fix works great with 17.0.3, thanks

Comment 20

[u279076]

(In reply to Zdenek Kraus from comment #19)
> Antony, fix works great with 17.0.3, thanks

Thanks Zdenek.

Comment 21

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(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

[u279076]

Thanks Dave, I've gone ahead and filed bug 851502 to develop the test.

Comment 23

[Mihaela Velimiroviciu (:mihaelav)]

The automated test for this was tracked in bug 851502. Marking in-qa-testsuite+