It is a new crash signature that exists in 4.0b7, b8pre. It is #133 top crasher in 4.0b7 for the last week. Here are some useful comments: "tried to turn off hardware acceleration" "Firefox crashes every single time I try and turn off hardware acceleration in the settings. I am doing this because I am running a GPU client of Folding@home constantly in the background and Firefox doesn't get on well with this when hardware acceleration is on." "It crashed when I tried to disable the option "Use Hardware Acceleration When Available". Please improve the rendering of the fonts." Signature cairo_d2d_surface_create_for_texture UUID c30d9924-9aa2-4abc-b9a3-a51702101112 Time 2010-11-12 10:49:14.581543 Uptime 51041 Last Crash 51046 seconds (14.2 hours) before submission Install Age 51041 seconds (14.2 hours) since version was first installed. Product Firefox Version 4.0b7 Build ID 20101104142426 Branch 2.0 OS Windows NT OS Version 6.1.7601 Service Pack 1, v.721 CPU x86 CPU Info GenuineIntel family 6 model 30 stepping 5 Crash Reason EXCEPTION_ACCESS_VIOLATION_WRITE Crash Address 0x4 App Notes AdapterVendorID: 1002, AdapterDeviceID: 68a0 Frame Module Signature [Expand] Source 0 xul.dll cairo_d2d_surface_create_for_texture gfx/cairo/cairo/src/cairo-d2d-surface.cpp:3880 1 xul.dll gfxD2DSurface::gfxD2DSurface gfx/thebes/gfxD2DSurface.cpp:62 2 xul.dll mozilla::layers::LayerManagerD3D10::CreateOptimalSurface gfx/layers/d3d10/LayerManagerD3D10.cpp:316 3 xul.dll nsCanvasRenderingContext2D::SetDimensions content/canvas/src/nsCanvasRenderingContext2D.cpp:1086 4 xul.dll nsHTMLCanvasElement::UpdateContext content/html/content/src/nsHTMLCanvasElement.cpp:514 5 xul.dll nsHTMLCanvasElement::GetContext content/html/content/src/nsHTMLCanvasElement.cpp:447 6 xul.dll nsIDOMHTMLCanvasElement_GetContext obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:20968 7 mozjs.dll js::Interpret js/src/jsinterp.cpp:4744 8 mozjs.dll js::RunScript js/src/jsinterp.cpp:665 9 mozjs.dll js::Invoke js/src/jsinterp.cpp:768 10 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:881 11 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4898 12 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694 13 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:577 14 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 15 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 16 xul.dll mozilla::widget::TaskbarPreview::DrawBitmap widget/src/windows/TaskbarPreview.cpp:406 More reports at: http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=cairo_d2d_surface_create_for_texture
blocking2.0: --- → ?
Summary: [D2D] Firefox 4.0b7 crash [@ cairo_d2d_surface_create_for_texture ] → [D2D] Firefox 4.0b7 crash [@ cairo_d2d_surface_create_for_texture ] when trying to turn off HW acceleration
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
Hrm, I think I understand what happens here. When we update the RenderMode the LayerManagers should be cancelled for all Widgets. Not just the one that triggered the render mode update. Reliable STR are as follows: - Start firefox with HW accel on - Ctrl+N to open new window - Go into options in new window - Disable hardware acceleration - Mouse-over taskbar icon to draw preview for the other window
Created attachment 491313 [details] [diff] [review] Clear all D3D10 layer managers This patch clears all D3D10 layer managers when the D2D device changes/becomes unavailable. It's not particularly pretty though.
Created attachment 491328 [details] [diff] [review] Check D3D10 device upon GetLayerManager As per IRC discussion this will check the D3D10 device when the layer manager is retrieved.
Comment on attachment 491328 [details] [diff] [review] Check D3D10 device upon GetLayerManager Looks good, but I think we need an additional patch to prevent the crash if a D3D10 device goes dead after the GetLayerManager() has succeeded. Right?
Attachment #491328 - Flags: review?(roc) → review+
(In reply to comment #4) > Comment on attachment 491328 [details] [diff] [review] > Check D3D10 device upon GetLayerManager > > Looks good, but I think we need an additional patch to prevent the crash if a > D3D10 device goes dead after the GetLayerManager() has succeeded. Right? A D3D10 device never goes dead. It continues working, it might not display though, this is why UpdateRenderMode is called each paint to check if it's still 'working' if it's not, it will change the render mode, and this patch should automatically adapt all the layer managers. The crash in this case was UpdateRenderMode NULLs out the D2D device causing D2D surface creation functions to stop working.
Is this patch going to fix bug 612515? (same STR)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Crash Signature: [@ cairo_d2d_surface_create_for_texture ]
You need to log in before you can comment on or make changes to this bug.