It's currently #3 top crasher in today's build. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=635fcc11d2b1&tochange=4cb8f88213f5 It's likely a regression from bug 797314. Signature gfxContext::PushGroupAndCopyBackground(gfxASurface::gfxContentType) More Reports Search UUID 2fffef46-f0f6-4aa6-a9ce-a05e02121005 Date Processed 2012-10-05 08:05:11 Uptime 11462 Last Crash 3.9 hours before submission Install Age 9.1 hours since version was first installed. Install Time 2012-10-04 23:00:51 Product Firefox Version 18.0a1 Build ID 20121004030525 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 23 stepping 7 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x689c, AdapterSubsysID: 034a1043, AdapterDriverVersion: 8.961.0.0 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ EMCheckCompatibility True Adapter Vendor ID 0x1002 Adapter Device ID 0x689c Total Virtual Memory 4294836224 Available Virtual Memory 3533877248 System Memory Use Percentage 55 Available Page File 9163833344 Available Physical Memory 3827302400 Frame Module Signature Source 0 xul.dll gfxContext::PushGroupAndCopyBackground gfx/thebes/gfxContext.cpp:1533 1 xul.dll mozilla::layers::BasicLayerManager::PushGroupForLayer gfx/layers/basic/BasicLayerManager.cpp:81 2 xul.dll mozilla::layers::BasicThebesLayer::PaintThebes gfx/layers/basic/BasicThebesLayer.cpp:131 3 mozglue.dll je_free memory/mozjemalloc/jemalloc.c:6575 4 xul.dll xul.dll@0xb547f 5 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayerManager.cpp:932 6 xul.dll mozilla::layers::BasicLayerManager::PaintSelfOrChildren gfx/layers/basic/BasicLayerManager.cpp:828 7 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayerManager.cpp:932 8 xul.dll mozilla::layers::BasicLayerManager::EndTransactionInternal gfx/layers/basic/BasicLayerManager.cpp:578 9 gkmedias.dll mozilla::gfx::DrawTargetCairo::PushClipRect gfx/2d/DrawTargetCairo.cpp:695 10 xul.dll mozilla::layers::BasicLayerManager::EndTransaction gfx/layers/basic/BasicLayerManager.cpp:503 11 xul.dll mozilla::PaintInactiveLayer layout/base/FrameLayerBuilder.cpp:2019 12 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:3224 13 xul.dll mozilla::layers::BasicThebesLayer::PaintThebes gfx/layers/basic/BasicThebesLayer.cpp:139 More reports at: https://crash-stats.mozilla.com/report/list?signature=gfxContext%3A%3APushGroupAndCopyBackground%28gfxASurface%3A%3AgfxContentType%29

Hrm, this would happen if creating the new DrawTarget would fail, I wonder why that would happen though. It could happen in OOM but that doesn't seem likely at such high frequency. Is anyone able to get STR for this?

Also, it would be interesting to know if is this still happening after bug 797797 landed.

(In reply to Bas Schouten (:bas) from comment #2) > Also, it would be interesting to know if is this still happening after bug > 797797 landed. Yes, it still happens in 18.0a1/20121006 and above but at a lower volume.

Still #4 top browser crasher in today's build.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 crashed like bp-54a97688-9174-4e9f-abda-6c0072121010 when previewing a tab in the taskbar that was yet to be loaded after a session restore. Might be related to bug 793175 or to the proxy detection wonkyness I described at http://forums.mozillazine.org/viewtopic.php?p=12361691#p12361691

Bas - if this is difficult to reproduce/investigate, perhaps we should consider temporarily backing bug 797314 out to double verify it's the cause.

(In reply to Alex Keybl [:akeybl] from comment #6) > Bas - if this is difficult to reproduce/investigate, perhaps we should > consider temporarily backing bug 797314 out to double verify it's the cause. That patch should only have made things better by reducing memory usage/leakage problems. I'd like to look at this a little more. I've found a bug related to the gradient cache that would cause crashes for taskbar previews but they shouldn't have this signature. Let's get a fix for that in at least. I still suspect the people crashing on this out in the open are OOM-ing, but it's hard to say without information from someone seeing specifically this crash. I'll try to reproduce locally more actively.

Bas, Here it crashes rather consistently on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 bp-6f01085b-89e7-46c0-9c67-aba8a2121011 Please let me know if you need me to collect anything from the problematic system.

(In reply to alex_mayorga from comment #8) > Bas, > > Here it crashes rather consistently on Mozilla/5.0 (Windows NT 6.1; Win64; > x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 > > bp-6f01085b-89e7-46c0-9c67-aba8a2121011 > > Please let me know if you need me to collect anything from the problematic > system. Memory usage when the crash occurs would be a useful first info. The crash we're seeing in PushClipsToDT is probably the same cause as this one except with ::PushGroup.

Bas, Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121011030552 crashed again like bp-73a44b92-bfd1-4416-bbe7-f0be42121011 The Physical Memory usage was ~61% and firefox.exe was using ~550,000 K at the time of the crash. This laptop has 4 GB of total RAM. Please see also https://bugzilla.mozilla.org/show_bug.cgi?id=793175#c25 for some screen captures of visual glitches that occur on or around these crashes.

(In reply to alex_mayorga from comment #10) > Bas, > > Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 > ID:20121011030552 crashed again like bp-73a44b92-bfd1-4416-bbe7-f0be42121011 > > The Physical Memory usage was ~61% and firefox.exe was using ~550,000 K at > the time of the crash. > > This laptop has 4 GB of total RAM. > > Please see also https://bugzilla.mozilla.org/show_bug.cgi?id=793175#c25 for > some screen captures of visual glitches that occur on or around these > crashes. Hrm, so OOM seems unlikely, does that data include the total Working Set (select the Column under the 'view' element in Task Manager) or just the Private Working Set?

Bas, ~550,000 K was the "Memory (Private Working Set)". For comparison, right now firefox.exe is using ~740,000 K for "Working Set (Memory)" and ~670,000 K for "Memory (Private Working Set)" Copying the bug comment I referenced before for clarity: "In case it is of interest, these are some screen captures of visual oddities that happen on or around these crashes: http://imm.io/HqKp The URL bar disappears from the preview and the window's border overflows to the second monitor, similar or related to bug 724940 http://imm.io/HqKM The whole preview is blank and the window's border overflows too, similar or related to bug 724940 http://imm.io/HnnJ Nightly button and tabs become transparent, perhaps bug 798224"

Hrm, so no OOM. This is starting to become a real mystery :s. All those values look pretty healthy. We need to find out what error is reported by Azure on DrawTarget creation, are you by any chance in a position to run debug builds?

Bas, I can install software in the problematic system, is there a guide somewhere on how "to run debug builds"?

Bas, FWIW all the crashes point to http://hg.mozilla.org/mozilla-central/annotate/ec10630b1a54/gfx/thebes/gfxContext.cpp#l1534 But that's a bit above my current skill set =S

(In reply to alex_mayorga from comment #15) > Bas, > > FWIW all the crashes point to > http://hg.mozilla.org/mozilla-central/annotate/ec10630b1a54/gfx/thebes/ > gfxContext.cpp#l1534 > > But that's a bit above my current skill set =S Yeah, the question is -why- mDT is NULL there. If you were running a build with logging it should tell you why. I'm not sure how to run a build with logging without doing your own build. Perhaps someone reading this can enlighten us?

Maybe if I check that box for "Need additional information from anyone" someone would notice it. Let's see...

alex: The needinfo flags doesn't help, nobody will do a search for bugs with that flag and the next comment (this one) will remove it anyway bas: Is that logging to a file or is a debugger required ? If he needs only a debug build he could use for example this build: ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-win32-debug/1350117447/firefox-19.0a1.en-US.win32.zip

STR: 1. Open Gmail in new tab. 2. Use Windows Taskbar preview and hover Gmail tab. 3. Nightly crash: https://crash-stats.mozilla.com/report/index/bp-abfe1191-53c0-4162-b216-16a052121015 BTW> Only when HWA on.

Not tracking for release as this is no more a top crasher

Crashes stopped spiking after 19.0a1/20121023 and 18.0a2/20121030. The working windows for the spike are: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=48502b61a63e&tochange=93cc1ee94291 http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=97c6c326435e&tochange=2b2d7457e130 It might have been fixed by bug 803949 or bug 758531 as stated by Bas in comment 9. semtex2, can you still reproduce it?

(In reply to Scoobidiver from comment #21) > Crashes stopped spiking after 19.0a1/20121023 and 18.0a2/20121030. The > working windows for the spike are: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=48502b61a63e&tochange=93cc1ee94291 > http://hg.mozilla.org/releases/mozilla-aurora/ > pushloghtml?fromchange=97c6c326435e&tochange=2b2d7457e130 > It might have been fixed by bug 803949 or bug 758531 as stated by Bas in > comment 9. > > semtex2, can you still reproduce it? No, seems to be fixed for me as well.

The signature seems to be back since the 2013-02-07 build, with multiple crashes in every build since then.

I get this crash when I install/uninstall Catalyst while Firefox is running. Windows 8 x64, AMD Radeon HD 7700 Series

In Firefox 19.0, this crash shows a significant skew towards nvidia graphics hardware and shows up much less frequently with Intel graphics.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #25) > In Firefox 19.0, this crash shows a significant skew towards nvidia graphics > hardware and shows up much less frequently with Intel graphics. I wonder if this is simply occuring on a driver reset/crash. We should really somehow have an automated test for that situation.

Yes, I think that is very likely. I think I've seen this crash personally when windows update updates my nvidia driver, for example, which causes a graphics reset.

This has been rising yesterday, and I heard NVidia shipped a driver update, so that could match.

It's #16 browser crasher in 21.0, #22 in 22.0b2 and 23.0a2, and #18 in 24.0a1. (In reply to Bas Schouten (:bas.schouten) from comment #9) > Memory usage when the crash occurs would be a useful first info. The crash > we're seeing in PushClipsToDT is probably the same cause as this one except > with ::PushGroup. I think so based on correlations: 99% (440/443) vs. 13% (13551/107853) d3d11.dll 0% (1/443) vs. 0% (7/107853) 6.2.8400.0 4% (16/443) vs. 0% (223/107853) 6.2.9200.16384 17% (75/443) vs. 1% (1582/107853) 6.2.9200.16420 0% (1/443) vs. 0% (46/107853) 6.2.9200.16440 78% (347/443) vs. 11% (11643/107853) 6.2.9200.16492 100% (443/443) vs. 18% (19104/107853) d2d1.dll 0% (2/443) vs. 1% (1085/107853) 6.1.7600.16385 0% (1/443) vs. 1% (1495/107853) 6.1.7601.17514 0% (1/443) vs. 0% (5/107853) 6.2.8400.0 4% (16/443) vs. 0% (187/107853) 6.2.9200.16384 17% (75/443) vs. 1% (1428/107853) 6.2.9200.16420 0% (1/443) vs. 0% (46/107853) 6.2.9200.16440 78% (347/443) vs. 10% (10692/107853) 6.2.9200.16492

bas, is this related or a dupe of bug 805406 is #19 on 23.0.1 and #56 on 24beta topcrash lists

I believe the cause is exactly the same, so is the underlying bug.

I believe this has morphed into gfxContext::PushGroupAndCopyBackground(gfxContentType) on Fx27 https://crash-stats.mozilla.com/report/index/d59e6096-fc98-4e1f-9df6-bfa872131007 with 100% (16/16) vs. 53% (635/1209) d3d11.dll It's #9 with the above signature on Nightly (Fx27).

Current Rank > Firefox 29: #3 @ 2.01% > Firefox 28: #8 @ 1.29% > Firefox 27: #10 @ 0.68% > Firefox 26: #21 @ 0.52%

(In reply to Bas Schouten (:bas.schouten) from comment #31) > I believe the cause is exactly the same, so is the underlying bug. Between the two bugs (crash signatures) they currently account for 5% of all crashes on 27betas.

This signature jumped from 0 to ~100 crashes per million ADI from 26 to 27 on beta, it's probably closely related to bug 805406 where we look into this increase already.

Ah, forgot that the signature morphed as described in comment #33, so 26->27 only made it go up from ~30 to ~100 crashes per million ADI.

Just crashed like this on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140225030201 CSet: e3daaa4c73dd Report ID Date Submitted bp-cfd8dce2-5d24-482c-9dde-e963c2140226 25/02/2014 07:50 p.m. I was indeed fiddling with the nvidia drivers on the system at the time of the crash.

Nominating for tracking since this is #14 on Firefox 28.

If this is related to bug 805406 is it also fixed on 30? We're too late for any kind of speculative work on FF28 so wontfixing based on that. We might even want to dupe this.

Given comment #31, I'm going ahead and just duping this to 805406, any action will be tracked there anyhow. (In reply to Lukas Blakk [:lsblakk] from comment #40) > If this is related to bug 805406 is it also fixed on 30? It's also not fixed, even though the patches were supposed to also help this. :-/