Closed Bug 704762 Opened 11 years ago Closed 9 years ago

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


(Core :: Graphics, defect)

Windows XP
Not set



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


(Reporter: scoobidiver, Assigned: jrmuizel)



(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 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:
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 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>
var ctx=document.getElementById("myCanvas").getContext("2d");

It wont crash if the canvas is not in the DOM tree, ie,
var ctx=document.createElement("canvas").getContext("2d");

Or followed by further operation, ie,
<canvas id="myCanvas"></canvas>
var ctx=document.getElementById("myCanvas").getContext("2d");; // prevent crash
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
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.
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.