Closed Bug 622886 Opened 9 years ago Closed 9 years ago
spike in crashes [@ gfx
Context::gfx Context(gfx ASurface*) ]
It is a residual crash signature that exists in 3.6 and trunk builds. There is a spike in crashes from 4.0b9pre/20110103. It is #1 top crasher in this build. Signature gfxContext::gfxContext(gfxASurface*) UUID 0b92041d-45e1-4048-ae54-332162110104 Time 2011-01-04 09:46:20.322134 Uptime 566 Last Crash 573 seconds (9.6 minutes) before submission Install Age 649 seconds (10.8 minutes) since version was first installed. Product Firefox Version 4.0b9pre Build ID 20110103030359 Branch 2.0 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 14 stepping 12 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x4 User Comments App Notes AdapterVendorID: 10de, AdapterDeviceID: 01d7 Frame Module Signature [Expand] Source 0 xul.dll gfxContext::gfxContext gfx/thebes/gfxContext.cpp:64 1 xul.dll mozilla::layers::ThebesLayerD3D9::DrawRegion gfx/layers/d3d9/ThebesLayerD3D9.cpp:498 2 xul.dll mozilla::layers::ThebesLayerD3D9::RenderLayer gfx/layers/d3d9/ThebesLayerD3D9.cpp:224 3 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:317 4 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:317 5 xul.dll mozilla::layers::LayerManagerD3D9::Render gfx/layers/d3d9/LayerManagerD3D9.cpp:300 6 xul.dll mozilla::layers::LayerManagerD3D9::EndTransaction gfx/layers/d3d9/LayerManagerD3D9.cpp:157 7 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:480 8 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1463 9 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:6108 The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a05e91710adb&tochange=c20f34eefa5d More reports at: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=gfxContext%3A%3AgfxContext%28gfxASurface*%29
Looks like this could be http://hg.mozilla.org/mozilla-central/rev/b4e0f47b628d
I'm mildly disturbed that destinationSurface can be null, but I guess the Windows API calls in OpaqueRenderer::Begin could be failing for mysterious reasons. This should prevent a crash.
Attachment #501114 - Flags: review?(bas.schouten)
This is the #1 crash on the trunk right now - regression of some kind caused this spike. Shouldn't this be a candidate for beta9?
The number of crashes increased to over 500 yesterday. It's probably worth trying to investigate what triggered this even if we don't block beta9. It could potentially explode up.
Marking beta9 for now.
blocking2.0: ? → beta9+
One (not always reliable) way to reproduce this bug is to open many new tabs in a SeaMonkey(!) trunk build with about:blank to display in a new tab. I just hold Ctrl+T for one or two seconds and then release that shortcut, a second later it crashes.
Comment on attachment 501114 [details] [diff] [review] wallpaper I'm concerned that due to the increased memory usage if we've got several large component alpha layers actively working we're running into OO VRAM situations.
Attachment #501114 - Flags: review?(bas.schouten) → review+
On my laptop, I can reproduce this bug when I surf to http://www.guilhermebarbosa.com/AUSTRALIA/Aussie-Pelican/13943281_NHcWB and just hover above the big picture. Normally some menu appears within the picture, but I get an instant crash.
instant rash on zooming image in my case http://crash-stats.mozilla.com/report/index/bp-a28d5fd9-355c-48d3-91b1-69dab2110107 http://crash-stats.mozilla.com/report/index/bp-1510b3bd-cfaa-4b06-bc00-59c9b2110107
I neglected to give my Email address for all my crashes related to bug 622886, so here they all are: My Crash ID's bp-62f74023-75f6-4bf7-9d97-cb91c2110106 bp-98fb33e0-3ca8-4ac6-b594-d80de2110106 bp-2eb018ad-8b51-4de7-9f7b-aff972110106 bp-da8678e8-56e2-4578-9ab6-1a48d2110106 bp-b6a3786c-364f-4b04-905a-6d13e2110106 bp-4d892e20-2775-4cca-a2e6-2ee642110106 bp-809d06bb-4626-41a8-89d4-aea932110106 bp-be7aee99-45b8-4a03-916f-1fe7c2110106 bp-9061b1e9-4c5e-4af2-ab01-04a342110106 bp-230f7b3f-58e4-4164-a0d2-28b3d2110106 bp-76cd268d-0683-439a-9dbe-3df4a2110106 bp-f1e08f5d-a715-484b-bffb-9f9402110106 bp-b7afc3a4-f012-4283-a869-7a8b22110106 bp-52772f21-4363-431a-84e2-e2d8f2110106 bp-23194782-78a5-4753-bd8b-075a42110106 bp-28700fd9-e009-413a-a0fc-a65a92110106 bp-c516b884-357e-488c-b2b2-fda6d2110106 bp-52db4677-ae87-4579-bc40-5b0e12110106 bp-d47ae0a7-8275-4640-8e20-80b852110106 bp-4924e70d-fe81-4e74-be16-5957b2110106 bp-0bc3dd4b-716d-4dd1-b157-746bf2110106 bp-bef1e078-010f-4aad-a71f-a650b2110106 bp-f866945e-3ddd-4aac-a4d7-d59cf2110106 bp-2b97b0f0-3d25-4048-a7bd-2d68a2110105 bp-ee9201cb-f004-485c-96e1-02d492110105 bp-19343dbb-c350-41f1-8e33-353fa2110104 bp-5758fc71-ded2-480e-92de-a1e622110103 If about:config pref: layers.prefer-opengl , is set to true or disabling HWA through the Options window this type of crash doesn't occur for me anymore.
Is there something we have ready to checkin for this? It's still our top crasher and it's rising. I really don't think we want to ship beta9 without trying to get rid of this. What's the status?
Pushed "wallpaper" patch: http://hg.mozilla.org/mozilla-central/rev/906f834203ff Not sure if the intention was to investigate this further and come up with a non-wallpaper patch, so I'm leaving this open. Bas/roc: please close if we're done here.
Target Milestone: --- → mozilla2.0b9
Crashes are still happening in 4.0b9pre/20110108 so it is not fully fixed.
(In reply to comment #14) > Crashes are still happening in 4.0b9pre/20110108 so it is not fully fixed. I can confirm: My crash ID's bp-308ad776-fe40-46b4-8a11-e21a92110108 bp-b68fa935-0524-4fbe-99f1-74aff2110108
Assignee: bas.schouten → roc
Attachment #502327 - Flags: review?(bas.schouten)
(In reply to comment #7) > I'm concerned that due to the increased memory usage if we've got several large > component alpha layers actively working we're running into OO VRAM situations. I doubt it. We might be running out of VRAM, and component alpha might make it worse, but we'd definitely see a lot of OOVRAM crashes without component alpha as well if that was the case.
9 years ago
Whiteboard: [hardblocker] → [hardblocker][needs review]
Comment on attachment 502327 [details] [diff] [review] part 2 This looks fine to me.
Attachment #502327 - Flags: review+
Attachment #502327 - Flags: review?(bas.schouten) → review+
Let's try to shoehorn this simple null check into beta9
Whiteboard: [hardblocker][needs review] → [hardblocker]
Should be fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Do we understand what was the root cause of these crashes?
No. It looks like D3D surface creation failed, but we don't know why.
(In reply to comment #23) > No. It looks like D3D surface creation failed, but we don't know why. Ok. I've filed a follow up (bug 624801) to figure out why.
(In reply to comment #21) > Should be fixed. yup. last build with crashes is 2011011000
Status: RESOLVED → VERIFIED
Crash Signature: [@ gfxContext::gfxContext(gfxASurface*) ]
You need to log in before you can comment on or make changes to this bug.