Closed Bug 704762 Opened 14 years ago Closed 12 years ago

Startup crash in mozilla::layers::SwapChainD3D9::PrepareForRendering

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox9 + ---
firefox10 + ---
firefox-esr10 - wontfix

People

(Reporter: scoobidiver, Assigned: jrmuizel)

References

Details

(Keywords: crash, csectype-dos)

Crash Data

It's #74 top crasher in 9.0b2. It happens mainly on Windows XP. Signature mozilla::layers::SwapChainD3D9::PrepareForRendering() UUID f291b041-98ec-4160-907e-ed74b2111122 Date Processed 2011-11-22 23:38:46.894539 Uptime 5 Install Age 12.6 hours since version was first installed. Install Time 2011-11-22 19:03:08 Product Firefox Version 11.0a1 Build ID 20111122030949 Release Channel nightly OS Windows NT OS Version 5.1.2600 Service Pack 3 Build Architecture x86 Build Architecture Info AuthenticAMD family 16 model 5 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0xc App Notes AdapterVendorID: 1002, AdapterDeviceID: 68b8, AdapterSubsysID: 1482174b, AdapterDriverVersion: 8.911.0.0 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ EMCheckCompatibility True Frame Module Signature [Expand] Source 0 xul.dll mozilla::layers::SwapChainD3D9::PrepareForRendering gfx/layers/d3d9/DeviceManagerD3D9.cpp:116 1 xul.dll mozilla::layers::LayerManagerD3D9::Render gfx/layers/d3d9/LayerManagerD3D9.cpp:320 2 xul.dll mozilla::layers::LayerManagerD3D9::EndTransaction gfx/layers/d3d9/LayerManagerD3D9.cpp:184 3 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:635 4 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1698 5 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:5472 6 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:389 7 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:885 8 xul.dll AttachedHandleEvent view/src/nsView.cpp:191 9 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:3614 10 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:3642 11 xul.dll nsWindow::OnPaint 12 xul.dll nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:633 13 user32.dll WinStationSendMessageW 14 ntdll.dll RtlUnicodeStringToAnsiString More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Alayers%3A%3ASwapChainD3D9%3A%3APrepareForRendering%28%29
It's now #4 top crasher in 9.0b2.
Bas, Benoit, or Jeff, can you take a look at this?
It's not super high volume - appearing at #100 on 9.0b5.
(In reply to Sheila Mooney from comment #3) > It's not super high volume - appearing at #100 on 9.0b5. It's a startup crash, so new 9.0 beta users hit that soon after the update process, not once in steady state (from Beta N to Beta N+1). It will be high in 9.0.
From the crash comments (Submitted: 2011-12-09 04:01:19-08) > close firefox > open html file which contains canvas.getContext("2d") > crash Bas/Benoit/Jeff - How common is this in the wild? Does that help us to investigate the issue?
We are tracking this for Fx9...do we still need to? Is there work to be done here or can we ship as-is?
It would be good to know what exactly is causing the crash here. Joe can you send me a minidump?
Assigning to Joe since he has next action on this tracked bug.
Assignee: nobody → joe
Just sent this to Jeff.
Assignee: joe → jmuizelaar
The only reason I could see this happening is if EndTransaction was called after Destroy() has been called. I'm not 100% sure what could cause this.
It is a startup crash and occured when calling getContext("2d") by a canvas element in the DOM tree. Demo: startup Firefox by a html file with following codes: <canvas id="myCanvas"></canvas> <script> var ctx=document.getElementById("myCanvas").getContext("2d"); </script> It wont crash if the canvas is not in the DOM tree, ie, <script> var ctx=document.createElement("canvas").getContext("2d"); </script> Or followed by further operation, ie, <canvas id="myCanvas"></canvas> <script> var ctx=document.getElementById("myCanvas").getContext("2d"); ctx.save(); // prevent crash </script>
This took a spike on Aug 6th to be the topcrasher for 10.0.6esr - is this possibly related to bug 734921 and the google doogle issue?
Yes, as the URLs show and as the spike has ended, this is the ESR version of bug 773097. I guess we should port its patch to ESR as well.
Although the stack and symptoms are different, the parallel spike of crashes is pretty convincing that it's related to bug 773097. If it's not fixed by that one, though, the numbers will likely dwindle into such insignificance that we're unlikely to find a different fix. In ESR there was also a corresponding spike (only 0.2 as big) at gfxASurface::Release() whose stacks look more directly like bug 773097
Depends on: 773097
Keywords: csec-dos
No longer depends on: 773097
Bug 773097 is landed on ESR and is being tracked for ESR 15+ so I'm removing tracking on this bug.
There's only one crash in 22.0 so not enough to track it in Bugzilla.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.