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

RESOLVED FIXED in Firefox 36

Status

()

P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mayankleoboy1, Assigned: mattwoodrow)

Tracking

(Blocks: 1 bug, {crash, crashreportid})

Trunk
mozilla38
x86
Windows 7
crash, crashreportid
Points:
---

Firefox Tracking Flags

(firefox36 fixed, firefox37+ fixed, firefox38 fixed)

Details

(Whiteboard: [MemShrink:P2], crash signature)

Attachments

(15 attachments)

(Reporter)

Description

4 years ago
Posted file 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
(Reporter)

Comment 1

4 years ago
can repro pretty reliably by watching any 6-7 minute HTML5 video on youtube with 720p quality.
(Reporter)

Comment 2

4 years ago
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
Crash Signature: [@ moz_abort | pages_commit ]
Keywords: crash, crashreportid
Here is a link to all crashes: https://crash-stats.mozilla.com/report/list?signature=moz_abort%20|%20pages_commit
Blocks: 778617
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
Component: Untriaged → Graphics
Product: Firefox → Core
Whiteboard: [MemShrink]
That's a reasonable vsize-max-contiguous for a 64-bit build.
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.
(Assignee)

Comment 7

4 years ago
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/
ni? for comment 7
Flags: needinfo?(mayankleoboy1)
Whiteboard: [MemShrink] → [MemShrink:P2]
See Also: → bug 1127925
(Assignee)

Comment 9

4 years ago
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!
(Reporter)

Comment 10

4 years ago
(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?
(Assignee)

Comment 11

4 years ago
Unfortunately the changes didn't make it into the latest nightly, so those builds are required for now.
(Reporter)

Comment 12

4 years ago
memory repor with 96% memory usage shown
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 13

4 years ago
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 ?
(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.
(Assignee)

Comment 15

4 years ago
(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!
(Reporter)

Comment 16

4 years ago
(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.
(Reporter)

Comment 17

4 years ago
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.
(Assignee)

Comment 18

4 years ago
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.
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 19

4 years ago
So i should download the Win8 OPT build, and try to reproduce the crash and get a about:memory ?
(Reporter)

Comment 21

4 years ago
Cant repro with the build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-8ee0e38badfe/try-win64
Flags: needinfo?(mayankleoboy1)
I posted the wrong build link
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 24

4 years ago
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?
Flags: needinfo?(mayankleoboy1)
(Reporter)

Updated

4 years ago
Flags: needinfo?(jmuizelaar)
(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.
Flags: needinfo?(jmuizelaar)
(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.
(Assignee)

Comment 29

4 years ago
Oh, did you revert the changes to the media.windows-media-foundation.use-dxva pref?
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
(Reporter)

Comment 31

4 years ago
(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
Summary: OOM crash while watching a HTML5 video on Youtube → OOM crash while watching a HTML5 video on Youtube w/ AMD hardware
Summary: OOM crash while watching a HTML5 video on Youtube w/ AMD hardware → OOM crash while watching a HTML5 video on Youtube w/ AMD hardware and DXVA
(Reporter)

Comment 34

4 years ago
(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 ?
Flags: needinfo?(matt.woodrow)
(Reporter)

Comment 35

4 years ago
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.
Flags: needinfo?(mayankleoboy1)
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/
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 37

4 years ago
(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.
(Reporter)

Comment 38

4 years ago
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-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. )
Flags: needinfo?(mayankleoboy1)
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.
(Reporter)

Comment 41

4 years ago
(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.  :(
(Reporter)

Comment 42

4 years ago
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.
Here's a new build to try that reports more information:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-9fffd74d60aa/try-win32/

Please upload an about:memory report when you can.
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 44

4 years ago
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
Flags: needinfo?(mayankleoboy1)
(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?
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 46

4 years ago
(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.
Flags: needinfo?(mayankleoboy1)
(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.
(Reporter)

Comment 48

4 years ago
(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?
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 49

4 years ago
(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?
(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.
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 51

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

Updated

4 years ago
Priority: -- → P1
(Assignee)

Comment 52

4 years ago
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.
(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.
(Assignee)

Comment 54

4 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fd9ad57e851b
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-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 :)
Flags: needinfo?(matt.woodrow) → needinfo?(mayankleoboy1)
That build has a bug the does the counting wrong, this one should be better:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2085de16bf8
(Assignee)

Comment 57

4 years ago
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/jmuizelaar@mozilla.com-b7e55188664c/try-win32/

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-03724a1d320d/try-win32/
(Assignee)

Comment 58

4 years ago
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.
(Reporter)

Comment 59

4 years ago
(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.
(Assignee)

Comment 60

4 years ago
(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/mwoodrow@mozilla.com-d3a960d735fe/try-win32/
(Reporter)

Comment 61

4 years ago
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.
Flags: needinfo?(mayankleoboy1)
(Reporter)

Comment 62

4 years ago
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.
(Reporter)

Comment 63

4 years ago
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.
(Reporter)

Comment 64

4 years ago
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.
(Reporter)

Comment 65

4 years ago
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.
(Reporter)

Comment 66

4 years ago
 >(In reply to mayankleoboy1 from comment #65)

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

Comment 67

4 years ago
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.
(Assignee)

Comment 68

4 years ago
Assignee: nobody → matt.woodrow
Attachment #8565207 - Flags: review?(nical.bugzilla)
(Reporter)

Comment 69

4 years ago
(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

4 years ago
(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.
Tracking all MSE P1 bugs for Firefox 37.
status-firefox37: --- → affected
status-firefox38: --- → affected
tracking-firefox37: --- → +
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 on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

Nical is gone. This seems ok if you use UniquePtr intead of nsAutoPtr
Attachment #8565207 - Flags: review?(nical.bugzilla) → review+
(Assignee)

Comment 74

4 years ago
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.
(Assignee)

Comment 75

4 years ago
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.
Attachment #8565207 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/d5939eb82085
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox38: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8565207 [details] [diff] [review]
Always release the KeepAlive object

[Triage Comment]
Taking it after discussion with Anthony Jones
Attachment #8565207 - Flags: approval-mozilla-release+
Attachment #8565207 - Flags: approval-mozilla-aurora?
Attachment #8565207 - Flags: approval-mozilla-aurora+
status-firefox36: --- → affected
mayankleoboy1, thanks very much for your help in this bug!
Sylvestre, should this be approved for release, or for beta?
Flags: needinfo?(sledru)
At this point, release == beta :)
Flags: needinfo?(sledru)
(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.
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?
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 85

4 years ago
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.
Flags: needinfo?(matt.woodrow)
Matt have you seen bug 1175104 ? Sounds similar (at least, it's another crash in tab sharing)
Flags: needinfo?(matt.woodrow)
"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

4 years ago
(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.
Flags: needinfo?(dmajor)
File a bug under Socorro::General to add pages_commit to the prefix list.
Flags: needinfo?(dmajor)
(Assignee)

Updated

4 years ago
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.