612120 - [D2D] Firefox 4+ crash in mozilla::layers::ThebesLayerD3D10::RenderLayer (reported in kernelbase.dll or d3d10_1core.dll) mainly with NVIDIA cards

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

It is a new crash signature that exists in 4.0b6, b7, b8pre.
It is #184 top crasher in 4.0b7 for the last week.

Here are some useful comments:
"Hi! I'm using build 20101028 for this. Please see http://img.photobucket.com/albums/v694/ronx13/Other/Firefox%20Test%20Drive/759ee61f.jpg for the related crash of my NVIDIA driver that seems to accompany this occasionally"
"video driver crashed and recovered. has happened before without FF running so I don't think FF is the cause, but it seems FF can't handle it if it does."
"tab candy crash ?"

Signature	d3d10_1core.dll@0xa7ab
UUID	fc41860b-ca0a-4592-a6bb-9379d2101114
Time 	2010-11-14 06:33:18.691991
Uptime	5762
Last Crash	7190 seconds (2.0 hours) before submission
Install Age	250036 seconds (2.9 days) since version was first installed.
Product	Firefox
Version	4.0b7
Build ID	20101104142426
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	0x00000879 / 0x00000000
Crash Address	0x752e9617
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0a2d

Frame 	Module 	Signature [Expand] 	Source
0 	KERNELBASE.dll 	RaiseException 	
1 	d3d10_1core.dll 	d3d10_1core.dll@0xa7ab 	
2 	dxgi.dll 	CD3D10Device::DriverInternalError 	
3 	dxgi.dll 	_allmul 	
4 	dxgi.dll 	CDXGISwapChainBase<IDXGISwapChain>::PresentImpl 	
5 	dxgi.dll 	CDXGISwapChainBase<IDXGISwapChain>::Present 	
6 	xul.dll 	mozilla::layers::LayerManagerD3D10::Render 	gfx/layers/d3d10/LayerManagerD3D10.cpp:471
7 	xul.dll 	mozilla::layers::LayerManagerD3D10::EndTransaction 	gfx/layers/d3d10/LayerManagerD3D10.cpp:239
8 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:461
9 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1440
10 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:6088
11 	xul.dll 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:447
12 	xul.dll 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:413
13 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:912
14 	xul.dll 	HandleEvent 	view/src/nsView.cpp:161
15 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3502
16 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3530
17 	ntdll.dll 	RtlGetVersion 	
18 	xul.dll 	nsAString_internal::Finalize 	xpcom/string/src/nsTSubstring.cpp:186
19 		@0x6387305 

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=d3d10_1core.dll%400xa7ab

Comment 1

[Makoto Kato [:m_kato]]

On Windows 7 case is the following (top #39 today on 4.0b9pre)

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&date=2011-01-10%2015%3A00%3A00&signature=KERNELBASE.dll%400xb727&version=Firefox%3A4.0b9pre


When d310 throws un-handled exception (0x00000879), this crash occurs.

Comment 2

[Bas Schouten (:bas.schouten)]

Bjacob, is this correlated with any specific device/driver combination?

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Some of the first crash reports in the list:

0ca3  GT215 [GeForce GT 240]  (repeated 3 times)
06e8  G98 [GeForce 9200M GS]  (repeated 2 times)
0191  G80 [GeForce 8800 GTX]
0428  G86 [GeForce 8400M G]

So we already have 3 different generations of NVIDIA cards here.

It also isn't specific to one driver version: we have 258.96, 186.31, 197.16, 260.99 ... so it happens with old and new drivers alike.

Comment 4

[Bas Schouten (:bas.schouten)]

Anything in here that looks like ATI though?

There's reports on on the web of this 0x00000879 exception, for example there's someone reporting the following:

First-chance exception at 0x7676dde0 in Tutorial07.exe: Microsoft C++ exception: _com_error @ 0x0012f610.
D3D10: UM Driver Internal Error.
Removing Device.
D3D10: WARNING: : Device removal has been triggered with the for the following reason (DXGI_ERROR_DRIVER_INTERNAL_ERROR: There is strong evidence that the driver has performed an undefined operation). [ EXECUTION WARNING #379: DEVICE_REMOVAL_PROCESS_POSSIBLY_AT_FAULT ]
D3D10: Raising UM Driver Internal Error to continuable exception.First-chance exception at 0x7676dde0 in Tutorial07.exe: 0x00000879: 0x879.
Unhandled exception at 0x7676dde0 in Tutorial07.exe: 0x00000879: 0x879.

If this is indeed a continuable exception perhaps we should catch it and reinitialize our device when it occurs.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #4)
> Anything in here that looks like ATI though?

Out of a dozen crash reports, I had only seen NVIDIA.

You can easily check for yourself, see above crash-stats link, each crash report has a Vendor ID in the first tab.

Comment 6

[Joe Drew (not getting mail)]

This just happened to me not long after a display driver crash (and recovery).

Comment 7

[Joe Drew (not getting mail)]

Actually, twice; both were probably while closing tabs.

Comment 8

[Bas Schouten (:bas.schouten)]

(In reply to comment #7)
> Actually, twice; both were probably while closing tabs.

The volume of this is pretty low, do you suppose we should wrap the present call in a try block and catch exception 0x879?

Comment 9

[Scoobidiver (away)]

KERNELBASE.dll@0xb727 crash is #38 top crasher in 4.0b8 for the last week but stack traces are various.
d3d10_1core.dll@0xa7ab crash is #259 top crasher in 4.0b8 for the last week.

Comment 10

[Scoobidiver (away)]

May be a dupe of bug 612103.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

This crash:
http://crash-stats.mozilla.com/report/index/0e2f2bd7-0a6d-4f21-ad00-569092110117

has a build ID from January 15, whereas bug 612103 was landed on January 11. So it's probably not a dupe?

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Happens even with latest 260.99 driver:

http://crash-stats.mozilla.com/report/index/6dd0fc37-044e-496c-9ec3-4493a2110103

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

@ Bas:

(In reply to comment #8)
> (In reply to comment #7)
> > Actually, twice; both were probably while closing tabs.
> 
> The volume of this is pretty low, do you suppose we should wrap the present
> call in a try block and catch exception 0x879?

The volume is currently 200/week, making this the biggest unresolved driver crash that I know of, and it happens with latest driver, so it's very much worth trying to work around. Please go ahead with your plan :-)

Comment 15

[Scoobidiver (away)]

It is #26 top crasher in 4.0b10.

Comment 16

[David Mandelin [:dmandelin]]

I got this today:

https://crash-stats.mozilla.com/report/index/bp-8f584bf5-132a-4eef-965b-769112110301

It seems to be reproducible for me:

1. Load http://people.mozilla.org/~jmuizelaar/fishie/fishie-fast.html
2. Select 60,000 fishes
3. Open about:config in another tab
4. Toggle the option javascript.options.methodjit.content

Comment 17

[Scoobidiver (away)]

With the STR in comment 16, I can not reproduce in 4.0b12 (does not crash) and in the latest nightly (WebGL disabled!).
It is #85 top crasher in 4.0b12.

Comment 18

[Scoobidiver (away)]

> and in the latest nightly (WebGL disabled!).
I messed up 64-bit and 32-bit builds. I can not reproduce (does not crash), but I have an Intel GPU.

Comment 19

[The 8472]

I get a similar crash every time i do something canvas-related (e.g. opening tabcandy) after my system wakes up from hibernation. Win7 x64, nvidia card.

https://crash-stats.mozilla.com/report/index/bp-23b72f3e-6b1c-43fb-beca-c08f02110304

Comment 20

[Ho Yiu Yeung]

I'm using ATI HD 4850 for my main screen and left screen, and onboard AMD 785G for my right screen.  I don't remember how I got my crash.  Used to have a nVidia card but it is replaced last year.  Win7 x64.

https://crash-stats.mozilla.com/report/index/bdacdaf7-fb90-43b3-9deb-64d122110407

Comment 21

[The 8472]

(In reply to comment #16)
Can't reproduce it using that procedure on
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1
with
Nvidia 9600 GT, drivers: 8.17.12.7061

With the latest nightly my procedure from comment #19 also needs a slight modification:
1. Open FF
2. Open and close Tabcandy
3. Put windows into hibernation (suspend to disk)
4. Reboot
5. Enter tabcandy again (note the UI breakage)
6. Resize window -> Crash

A few nightlies ago it immediately crashed on step 5 instead of just breaking the UI.

Comment 22

[Robert Kaiser]

For the kernelbase.dll@0xb727 signature, the last week of crashes - https://crash-stats.mozilla.com/report/list?signature=kernelbase.dll%400xb727 - shows all kinds of versions, including 5.0 and 5.0a2, but not 6.0a1.

Comment 23

[Bas Schouten (:bas.schouten)]

(In reply to comment #22)
> For the kernelbase.dll@0xb727 signature, the last week of crashes -
> https://crash-stats.mozilla.com/report/list?signature=kernelbase.
> dll%400xb727 - shows all kinds of versions, including 5.0 and 5.0a2, but not
> 6.0a1.

What I'd say is the ones with exception 0x879 are D3D driver 'related'. The others also occur in 3.6/3.5 so shouldn't be related to this particular crash.

I still think we should try/catch Present, and treat exception 0x879 as a driver reset. 

Even though I can't find any documentation http://social.msdn.microsoft.com/Forums/en/direct3d/thread/567d1122-7c16-4452-b2fe-1bb71617ea84 seems to suggest the following is said by the debug layer: 

D3D10: UM Driver Internal Error.
Removing Device.
D3D10: WARNING: : Device removal has been triggered with the for the following reason (DXGI_ERROR_DRIVER_INTERNAL_ERROR: There is strong evidence that the driver has performed an undefined operation). [ EXECUTION WARNING #379: DEVICE_REMOVAL_PROCESS_POSSIBLY_AT_FAULT ]
D3D10: Raising UM Driver Internal Error to continuable exception.

Comment 26

[Benoit Jacob [:bjacob] (mostly away)]

A new occurence was reported today: bug 663932
https://crash-stats.mozilla.com/report/index/b4ee9ba1-1e71-402c-9dd6-e46122110512

This time it's from LayerManagerD3D10::Render but the signature is the same as before.

This crash signature, kernelbase.dll@0xb727, has happened more than 3000 (three thousand) times in Firefox 4 during the past week, making it the 46th crasher.

Comment 27

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #8)
> (In reply to comment #7)
> > Actually, twice; both were probably while closing tabs.
> 
> The volume of this is pretty low, do you suppose we should wrap the present
> call in a try block and catch exception 0x879?

The volume is high now so please try anything you can imagine ;-)

Comment 28

[The 8472]

(In reply to comment #22)
> For the kernelbase.dll@0xb727 signature, the last week of crashes -
> https://crash-stats.mozilla.com/report/list?signature=kernelbase.
> dll%400xb727 - shows all kinds of versions, including 5.0 and 5.0a2, but not
> 6.0a1.

There are now. I just had one under 7.0a1. Same STR as before: doing canvas-y things after hibernation.

Comment 29

[Marcia Knous [:marcia]]

The volume on the various signatures associated with this bug is not very high across all versions:

kernelbase.dll@0xcacd  41 crashes in the last week
d3d10_1core.dll@0xa7ab No crashes in the last week
kernelbase.dll@0xb760 No crashes in the last week
KERNELBASE.dll@0xa49d No crashes in the last week
kernelbase.dll@0xb727 1 crash in the last week

Comment 30

[Scoobidiver (away)]

The d3d10_1core.dll has now debug symbols.
The kernelbase.dll@0x9673 crash signature is tracked in bug 630197.
The kernelbase.dll@0xcacd crash signature is tracked in bug 720676.
I close it as incomplete.