1128170 - OOM crash while watching a HTML5 video on Youtube w/ AMD hardware and DXVA

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[Mayank Bansal]

Attachment: aboutsupport.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150130030232

Steps to reproduce:

I was on youtube, watching 3 videos on HTML5. 
While watching the 4th video, i noticed that the desktop memory reporter gadget on Windows as showing 96% memory use. Howver, the task manager showed only 900MB of "Private memory" used. Windows kept showing a "Windows is low on memory. Please close Nightly to avoid crashing" dialog box. I ignored it.

I did multiple "reduce memory" from about:memory, but there was no difference.
While in the midle of the 4th video, nightly crashed.


Actual results:

Crash.

https://crash-stats.mozilla.com/report/index/e09d9c32-f031-4fb5-b53e-3f4322150131

Comment 1

[Mayank Bansal]

can repro pretty reliably by watching any 6-7 minute HTML5 video on youtube with 720p quality.

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

This seesion didnt crash. However, the memory usage is 98% (of 4GB), as shown by desktop gadget. The memory in task manager is ~440 MB.

On another note, the "crash-firefox.exe" doesnt work on Nightlyx64

Comment 3

[Marcia Knous [:marcia]]

Here is a link to all crashes: https://crash-stats.mozilla.com/report/list?signature=moz_abort%20|%20pages_commit

Comment 4

[Andrew McCreight [:mccr8]]

Nothing in the about:memory report looks too terrible, except that the resident and vsize are very high:

2,524.18 MB ── resident
    3,436.48 MB ── vsize
8,378,684.29 MB ── vsize-max-contiguous

Also, the vsize-max-contiguous seems absurdly large...

Comment 5

[(Away)]

That's a reasonable vsize-max-contiguous for a 64-bit build.

Comment 6

[(Away)]

In other words this crash was due to exhaustion of physical (or pagefile) memory rather than address space.

The dump file shows 2190MB of shared write-combine regions, committed. So this is another instance of bug 1062065 and friends. Notably it's an ATI card this time.

Comment 7

[Matt Woodrow (:mattwoodrow)]

Could you please try one of the below builds and get an about:memory dump from there. They include some new counters that will hopefully help us track this down.

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win64/1422970107/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1422970107/

Comment 8

[Andrew McCreight [:mccr8]]

ni? for comment 7

Comment 9

[Matt Woodrow (:mattwoodrow)]

It would also be really good if you could test with the pref media.windows-media-foundation.use-dxva set to false (separately from the test where you get the memory dump).

Thanks!

Comment 10

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> Could you please try one of the below builds and get an about:memory dump
> from there. They include some new counters that will hopefully help us track
> this down.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win64/1422970107/
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win32/1422970107/

Will the latest nightly https://hg.mozilla.org/mozilla-central/rev/7c87286ce969  work, or are these builds necessary?

Comment 11

[Matt Woodrow (:mattwoodrow)]

Unfortunately the changes didn't make it into the latest nightly, so those builds are required for now.

Comment 12

[Mayank Bansal]

Attachment: memory-report.json.gz

memory repor with 96% memory usage shown

Comment 13

[Mayank Bansal]

And this is the corresponding crash:

https://crash-stats.mozilla.com/report/index/fb76f320-f62e-42ca-9328-b0b762150204

I have a low pagefile size - ~150MB only. Will increasing that improve the crash report ?

Comment 14

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #12)
> Created attachment 8558925 [details]
> memory-report.json.gz
> 
> memory repor with 96% memory usage shown

This shows:
2,215.72 MB ── d3d9-shared-textures

This suggests that we're accumulating these things a lot.

Comment 15

[Matt Woodrow (:mattwoodrow)]

(In reply to mayankleoboy1 from comment #13)
> And this is the corresponding crash:
> 
> https://crash-stats.mozilla.com/report/index/fb76f320-f62e-42ca-9328-
> b0b762150204
> 
> I have a low pagefile size - ~150MB only. Will increasing that improve the
> crash report ?

No, the small page file is great (it's why you're crashing instead of just consuming swap for a long time).

I'm starting some more builds that break this down further, will post when they're finished.

Thanks for helping with this!

Comment 16

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> It would also be really good if you could test with the pref
> media.windows-media-foundation.use-dxva set to false (separately from the
> test where you get the memory dump).
> 
> Thanks!


tried that, and everything is fine. No OOM, no crash.

Comment 17

[Mayank Bansal]

And i think the length of the video matters. It is easier to repro by watching 2 videos of ~ 6-7 minutes.  Smaller 2-3 minute videos dont really repro this.

Comment 18

[Matt Woodrow (:mattwoodrow)]

Took a little longer than I hoped.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8ee0e38badfe

Once the B's turn green (within an hour I hope), click on them and there should be a link to the builds in the bottom left.

Comment 19

[Mayank Bansal]

So i should download the Win8 OPT build, and try to reproduce the crash and get a about:memory ?

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Yep. You should be able to get it from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/

Comment 21

[Mayank Bansal]

Cant repro with the build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win64

Comment 22

[Jeff Muizelaar [:jrmuizel]]

I posted the wrong build link

Comment 23

[Jeff Muizelaar [:jrmuizel]]

It needs to be the 32 bit build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/

Sorry about that.

Comment 24

[Mayank Bansal]

I took my build from the one in comment 18 . I downloaded the 64 bit build.

You want me to try the 32 bit build only?

Comment 25

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #24)
> I took my build from the one in comment 18 . I downloaded the 64 bit build.
> 
> You want me to try the 32 bit build only?

Yes the 32 bit build only.

Comment 26

[Mayank Bansal]

cant repro with the 32 bit build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/

Comment 27

[Mayank Bansal]

Attachment: memory-report.json.gz

memory report from build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/  , but could not repro the leak.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #27)
> Created attachment 8559253 [details]
> memory-report.json.gz
> 
> memory report from build
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> com-8ee0e38badfe/try-win32/  , but could not repro the leak.

That's surprising and interesting.

Comment 29

[Matt Woodrow (:mattwoodrow)]

Oh, did you revert the changes to the media.windows-media-foundation.use-dxva pref?

Comment 30

[Jeff Muizelaar [:jrmuizel]]

If you did reset the use-dxva pref it might be worth trying builds from here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b7e55188664c

Comment 31

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #29)
> Oh, did you revert the changes to the
> media.windows-media-foundation.use-dxva pref?



media.windows-media-foundation.use-dxva;true

Comment 32

[Jeff Muizelaar [:jrmuizel]]

Here's the actual build directory:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b7e55188664c/try-win32-debug/

Comment 33

[Matt Woodrow (:mattwoodrow)]

You'll want the opt build - http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b7e55188664c/try-win32/

Comment 34

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #33)
> You'll want the opt build -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-b7e55188664c/try-win32/


I downloaded the build from here. Unfortunately, i will not be able to test the builds on youtube anymore, as i have a metered internet connection.

Howver, i have a few videos saved from youtube.  I played these videos in the build above, and reproduced the OOM crash.
Will that be fine ?

Comment 35

[Mayank Bansal]

Attachment: memory-report.json.gz

OOM from locally saved youtube videos.
Link of youtube viodeo is 
https://www.youtube.com/watch?v=q1UPMEmCqZo
https://www.youtube.com/watch?v=4lyUNs7eNhs

When i downloaded these videos a few years back, they were in the mp4 format.

Comment 36

[Jeff Muizelaar [:jrmuizel]]

Can you reproduce the OOM with the locally saved youtube videos with the build from comment 27?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/

Comment 37

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #36)
> Can you reproduce the OOM with the locally saved youtube videos with the
> build from comment 27?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> com-8ee0e38badfe/try-win32/


No, i can not repro the crash with the locally saved videos.  
Attaching the memory report anyway.

Comment 38

[Mayank Bansal]

Attachment: memory-report.json.gz

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8ee0e38badfe/try-win32/   about:memory report.

The crash is not reproducible.

(However, i found that the "  671.48 MB ── d3d9-shared-textures"  value increased from ~450 MB to ~670MB in a matter of 3-4 minutes. Make what you will of this. )

Comment 39

[Jeff Muizelaar [:jrmuizel]]

I've started some new builds to try to figure out what change caused you to not be able to reproduce the crash here:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=03724a1d320d
https://treeherder.mozilla.org/#/jobs?repo=try&revision=678274d88667
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f5068d5abf53
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1b385be03ed

As an aside, Mozilla would be happy to help pay for any internet overages that helping with this bug might cost you.

Comment 40

[Jeff Muizelaar [:jrmuizel]]

Here are the build directories:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-03724a1d320d/try-win32/
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-678274d88667/try-win32/
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f5068d5abf53/try-win32/
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d1b385be03ed/try-win32/

Comment 41

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #40)
> Here are the build directories:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-03724a1d320d/try-win32/
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-678274d88667/try-win32/


Both these builds had a OOM crash. 
In both the builds, it was more difficult to reproduce the crash. Both builds took a lot of time to start OOM'ing.  Which makes me suspect if comment 37 and comment 27 are correct  , as they might get the crash if i test for long enough.  :(

Comment 42

[Mayank Bansal]

Attachment: memory-report.comment 37json.gz

comment 26 , comment 27 , comment 37 are wrong :(

with the builds from https://hg.mozilla.org/try/rev/8ee0e38badfe  , i can reproduce the memory leak. It tooka long time - i had to play two 14 minute videos, and then replay one to get the OOM crash. 

sorry for the misdirection.

Comment 43

[Jeff Muizelaar [:jrmuizel]]

Here's a new build to try that reports more information:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-9fffd74d60aa/try-win32/

Please upload an about:memory report when you can.

Comment 44

[Mayank Bansal]

Attachment: memory-report.json.gz

about:memory for the build from comment 43.  I did start getting a "windows is out of memory. Please close Nihtly to prevent info loss" message.

I did a manual crash of firefox.exe 

https://crash-stats.mozilla.com/report/index/e7aeeea9-09c8-4855-ada7-509f12150209

Comment 45

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #44)
> Created attachment 8561207 [details]
> memory-report.json.gz
> 
> about:memory for the build from comment 43.  I did start getting a "windows
> is out of memory. Please close Nihtly to prevent info loss" message.
> 
> I did a manual crash of firefox.exe 
> 
> https://crash-stats.mozilla.com/report/index/e7aeeea9-09c8-4855-ada7-
> 509f12150209

How did you manually crash firefox?
This report shows different numbers from the previous ones. Does this build not reproduce the problem in the same way as the previous ones?

Comment 46

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #45)
> 
> How did you manually crash firefox?

from the crashfirefox.exe application.  
While testing/retesting some of the builds from comment 40 ( and sadly comment 26) , there was  no crash report, as in the crash reporter didnt come after the crash. So i thought that a manual crash would maybe help in diagnosing this bug.



> This report shows different numbers from the previous ones. Does this build
> not reproduce the problem in the same way as the previous ones?

Not sure what to say. All OOM messages seem the same to me. Anything exact you want to know?

On a pure subjective note, the buiold from comment 40 reproduced the OOM much faster than the builds from comment 40 and comment 26.

Comment 47

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #46)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #45)
> > 
> > How did you manually crash firefox?
> 
> from the crashfirefox.exe application.  
> While testing/retesting some of the builds from comment 40 ( and sadly
> comment 26) , there was  no crash report, as in the crash reporter didnt
> come after the crash. So i thought that a manual crash would maybe help in
> diagnosing this bug.

So the report from comment 42 produced the same way as comment 44? If so can you try getting another report? I'm hoping that it will have numbers that are closer to comment 42.

Comment 48

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #47)
 
> So the report from comment 42 produced the same way as comment 44? 

Here is what i observed:  
My baseline memory use is ~45% with nightly open. With builds from comment 40, the memory usage stays at approximately this value for a long time (30-40 minutes) while playing videos. Once the memory levels reach ~70%, the number start growing very quickly. In one instance, the numbers went from 70% to 95% in less than a minute. 

With the build from comment 43, i didnt notice such thing. As i said, the OOM stage was reached quite quickly, in about 15 minutes of video play.




> If so can you try getting another report? I'm hoping that it will have numbers that
> are closer to comment 42.

You want me to retest with build from comment 43 ? Any other instruction/ method i should follow?

Comment 49

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #47)
> 
> So the report from comment 42 produced the same way as comment 44? 

Now i remmeber:  while testing the build from comment 43, i was watching a movie on VLC player, while a video played in Firefox in the background (with muted audio). Would that make a difference?

Comment 50

[Jeff Muizelaar [:jrmuizel]]

(In reply to mayankleoboy1 from comment #48)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #47)
>  
> > So the report from comment 42 produced the same way as comment 44? 
> 
> Here is what i observed:  
> My baseline memory use is ~45% with nightly open. With builds from comment
> 40, the memory usage stays at approximately this value for a long time
> (30-40 minutes) while playing videos. Once the memory levels reach ~70%, the
> number start growing very quickly. In one instance, the numbers went from
> 70% to 95% in less than a minute. 
> 
> With the build from comment 43, i didnt notice such thing. As i said, the
> OOM stage was reached quite quickly, in about 15 minutes of video play.
> 

That's interesting... Not sure what would cause it though...

> 
> You want me to retest with build from comment 43 ? Any other instruction/
> method i should follow?

Yes, please retest. If you weren't using VLC during the previous tests it's probably worth testing without it again.

(In reply to mayankleoboy1 from comment #49)
> Now i remmeber:  while testing the build from comment 43, i was watching a
> movie on VLC player, while a video played in Firefox in the background (with
> muted audio). Would that make a difference?

It is possible that it could make a difference.

Comment 51

[Mayank Bansal]

Attachment: memory-report.json.gz

about:memory for build from comment 43, without any movie playing in VLC

Comment 52

[Matt Woodrow (:mattwoodrow)]

Jeff was that latest build from the same base changeset as the earlier ones that reproduced it?

Very weird that we're getting different numbers now, looks like a different leak.

Comment 53

[Jeff Muizelaar [:jrmuizel]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #52)
> Jeff was that latest build from the same base changeset as the earlier ones
> that reproduced it?

Nope. I'm going to try to do a new build today.

> Very weird that we're getting different numbers now, looks like a different
> leak.

Indeed.

Comment 54

[Matt Woodrow (:mattwoodrow)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fd9ad57e851b
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-fd9ad57e851b/try-win32/

That one is based on the revision we were using earlier.

Could you please test this one, and get an about:memory report. Thanks :)

Comment 55

[Jeff Muizelaar [:jrmuizel]]

That build has a bug the does the counting wrong, this one should be better:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2085de16bf8

Comment 56

[Matt Woodrow (:mattwoodrow)]

Build directory for the fixed version: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a2085de16bf8/try-win32/

Comment 57

[Matt Woodrow (:mattwoodrow)]

Can you also please retest and confirm the first of these builds crashes quickly, while the second take much longer. about:memory reports for both would be great.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b7e55188664c/try-win32/

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-03724a1d320d/try-win32/

Comment 58

[Matt Woodrow (:mattwoodrow)]

Are you doing anything special to reproduce these crashes? Multiple tabs open, video in a background tab etc?

Can you try in a clean profile too please.

Comment 59

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #58)
> Are you doing anything special to reproduce these crashes? Multiple tabs
> open, video in a background tab etc?

Yes. I get two videos playing: one in the active tab, another in the background tab.


I am unable to reproduce the OOM for the build from comment 56 .  Will keep trying though.

Comment 60

[Matt Woodrow (:mattwoodrow)]

(In reply to mayankleoboy1 from comment #59)
 
> I am unable to reproduce the OOM for the build from comment 56 .  Will keep
> trying though.

That's a bit worrying, that was based on the changeset that reliably reproduced the issue earlier.

Can you also try this new build please:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d3a960d735fe/try-win32/

Comment 61

[Mayank Bansal]

Attachment: memory-report.json.gz

memory report for buildconfig :   https://hg.mozilla.org/try/rev/a2085de16bf8  

 This is on a clean profile. This took a longish time to repro.  i had to replay the videos (one in foreground tab, the other in bacg tab)  multiple times. Also, i had to play a movie in VLC in foreground.

Comment 62

[Mayank Bansal]

Attachment: memory-report.json.gz

about:memory of build from comment 60 .

I had a tough time getting the OOM. The system got to ~79% of RAM in 2 replays of video. But to take it from 79% to 89% took ~10 replays.

Comment 63

[Mayank Bansal]

Attachment: memory-report.json.gz

another about:memory for build from comment 60. I used a slightly different method to repro this. I played two different 1.5 hour movies in mp4 format in two tabs.

Comment 64

[Mayank Bansal]

Attachment: memory-report.json.gz

memory report of build from comment 60. This is the same as the previous report, except that this time, it took less than 2 minutes to get a OOM.

Comment 65

[Mayank Bansal]

Attachment: memory-report.json.gz

I think i have found a reliable STR that gave me a OOM everytime i tried . It is :

1.Play a video which is capable of being played in Firefox. Usually youtube mp4 videos, or any other mp4 vids will also do. Try to take a video atleast 8-9 minutes in length.
2. Through the windows task manager, set teh processor affinity for "firefox.exe" to one core only (core 0) 

I have a intel i3-350M, which is a 2 core+2 hyperthreaded CPU. If i set the processor affinity to "core 0" only, i reliably get a OOM.

this is repro with builds from comment 60 and comment 56


(This STR may not be *the bug*, but it is atleast *a* bug)
the attached about:memory is the report of this STR.

Comment 66

[Mayank Bansal]

 >(In reply to mayankleoboy1 from comment #65)

Of course, this is with e10s disabled, and media.windows-media-foundation.use-dxva = true

Comment 67

[Matt Woodrow (:mattwoodrow)]

Another build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-d7158ab6a78f/try-win32/

I managed to reproduce something similar to what you were seeing, though at a much slower leak rate. This build should fix it, if it's the same issue.

Comment 68

[Matt Woodrow (:mattwoodrow)]

Attachment: Always release the KeepAlive object

Comment 69

[Mayank Bansal]

(In reply to Matt Woodrow (:mattwoodrow) from comment #67)
> Another build:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> com-d7158ab6a78f/try-win32/
> 
> I managed to reproduce something similar to what you were seeing, though at
> a much slower leak rate. This build should fix it, if it's the same issue.


I tried this build, and can not reproduce comment 65 (which was 100% repro before).

Comment 70

[avada]

(In reply to Matt Woodrow (:mattwoodrow) from comment #67)
> Another build:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.
> com-d7158ab6a78f/try-win32/
> 
> I managed to reproduce something similar to what you were seeing, though at
> a much slower leak rate. This build should fix it, if it's the same issue.

I also have leaking memory while playing HTML5 videos. But with an NVIDIA card on windows 8.1 and x64 builds.
For me it takes an hour or two of video watching to get really bad, up to 3-4 gigs of memory usage and the sluggishness that comes with it.

So I guess I'll try when the patch hits nightly if the leak still happens.

Comment 71

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking all MSE P1 bugs for Firefox 37.

Comment 72

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

Review of attachment 8565207 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/client/TextureClient.cpp
@@ +133,5 @@
>  
>    RefPtr<CompositableForwarder> mForwarder;
>    RefPtr<TextureClient> mWaitForRecycle;
>    TextureClient* mTextureClient;
> +  nsAutoPtr<KeepAlive> mKeep;

Use UniquePtr instead of nsAutoPtr

Comment 73

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

Nical is gone. This seems ok if you use UniquePtr intead of nsAutoPtr

Comment 74

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d5939eb82085


(In reply to mayankleoboy1 from comment #69)
> I tried this build, and can not reproduce comment 65 (which was 100% repro
> before).

Thanks for all your help!


(In reply to avada from comment #70) 
> I also have leaking memory while playing HTML5 videos. But with an NVIDIA
> card on windows 8.1 and x64 builds.
> For me it takes an hour or two of video watching to get really bad, up to
> 3-4 gigs of memory usage and the sluggishness that comes with it.
> 
> So I guess I'll try when the patch hits nightly if the leak still happens.

That would be great. Please file a new bug (and CC me) if you can still reproduce leaks once this is on nightly.

Comment 75

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

Approval Request Comment
[Feature/regressing bug #]: OMTC
[User impact if declined]: Slow leaks, seems to affect video particularly, but could leak on all pages when we have accelerated layers on windows.
[Describe test coverage new/current, TreeHerder]: Tested manually, confirmed by reporter.
[Risks and why]: Very low risk, just makes sure we don't leak a reference.
[String/UUID change made/needed]: None.

Comment 76

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d5939eb82085

Comment 77

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

[Triage Comment]
Taking it after discussion with Anthony Jones

Comment 78

[Liz Henry (:lizzard) (relman/hg->git project)]

mayankleoboy1, thanks very much for your help in this bug!

Comment 79

[Liz Henry (:lizzard) (relman/hg->git project)]

Sylvestre, should this be approved for release, or for beta?

Comment 80

[Sylvestre Ledru [:Sylvestre]]

At this point, release == beta :)

Comment 81

[Marcia Knous [:marcia]]

(In reply to Liz Henry :lizzard from comment #78)
> mayankleoboy1, thanks very much for your help in this bug!

Yes, thanks very much - if you would like a Firefox tshirt as a thank you, please send your mailing info and size to my email address.

Comment 82

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f778349535f7
https://hg.mozilla.org/releases/mozilla-beta/rev/67d9db36737e

Comment 83

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/67d9db36737e

Comment 84

[Vasilica Tamas, QA [:vtamas]]

I encountered this crash on Firefox 39 Beta 2 (20150601171003) and Firefox 39 RC (20150624153222). 
I was testing Tab Sharing from a browser to another when I hit on this crash and I had several opened sites like Google Maps, Google Plus, Twitter, Linkedin, Yahoo. Both browsers crashed at the same time.

The crash reports:
https://crash-stats.mozilla.com/report/index/5b6ef23e-56f9-4b71-aeeb-3e8f92150625
https://crash-stats.mozilla.com/report/index/4eab7b79-31b7-47fb-be78-e700c2150625

Graphics:
Adapter Description	ATI Radeon 3000 Graphics (Microsoft Corporation - WDDM v1.1)
Adapter Drivers	aticfx32 aticfx32 atiumdag atidxx32 atiumdva
Adapter RAM	512
Asynchronous Pan/Zoom	none
Device ID	0x9616
Direct2D Enabled	true
DirectWrite Enabled	true (6.3.9600.17795)
Driver Date	6-20-2012
Driver Version	8.97.10.6
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	00000000
Vendor ID	0x1002
WebGL Renderer	Google Inc. -- ANGLE (ATI Radeon 3000 Graphics (Microsoft Corporation - WDDM v1.1) Direct3D11 vs_4_0 ps_4_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Any thoughts about these crashes?

Comment 85

[Matt Woodrow (:mattwoodrow)]

This isn't obviously a graphics or video crash to me.

Definitely an OOM crash, hard to say what's using all the memory from the crash report though.

Comment 86

[Liz Henry (:lizzard) (relman/hg->git project)]

Matt have you seen bug 1175104 ? Sounds similar (at least, it's another crash in tab sharing)

Comment 87

[(Away)]

"moz_abort | pages_commit" is a generic signature. The graphics issue in this bug was just one way to reach it. There are many other ways to fail in that function and they are most likely unrelated to this bug.

We should put "pages_commit" on the skip list so that failures can be correctly attributed to the callers. I'll file a skiplist bug when I have some spare time, but if anyone can do it faster, feel free!

Comment 88

[alex_mayorga]

(In reply to David Major [:dmajor] from comment #87)
> "moz_abort | pages_commit" is a generic signature. The graphics issue in
> this bug was just one way to reach it. There are many other ways to fail in
> that function and they are most likely unrelated to this bug.
> 
> We should put "pages_commit" on the skip list so that failures can be
> correctly attributed to the callers. I'll file a skiplist bug when I have
> some spare time, but if anyone can do it faster, feel free!

How does a n00b do this?

Nightly was crash happy this morning and I found https://crash-stats.mozilla.com/report/index/69ab376e-1834-4241-ae9f-9a31d2150804 on the pile of reports.

There are over 8000 reports in the last 7 days if I'm reading https://crash-stats.mozilla.com/report/list?product=Firefox&signature=moz_abort+%7C+pages_commit correctly.

Comment 89

[(Away)]

File a bug under Socorro::General to add pages_commit to the prefix list.

Comment 90

[alex_mayorga]

¡Gracias David!

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1191055 FWIW