624109 - Startup crash in gfxWindowsPlatform::VerifyD2DDevice with iZ3D

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

It is a bug similar to bug 612264 and bug 607075.
It happens rarely.

Signature	gfxWindowsPlatform::VerifyD2DDevice(int)
UUID	1d0cee11-058c-4fe4-8e5f-4f5d62110108
Time 	2011-01-08 00:02:27.245894
Uptime	6
Last Crash	318 seconds (5.3 minutes) before submission
Install Age	444 seconds (7.4 minutes) since version was first installed.
Product	Firefox
Version	4.0b9pre
Build ID	20110107030356
Branch	2.0
OS	Windows NT
OS Version	6.0.6001 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 13
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x6ba06385
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0405

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	gfxWindowsPlatform::VerifyD2DDevice 	gfx/thebes/gfxWindowsPlatform.cpp:398
1 	xul.dll 	gfxWindowsPlatform::UpdateRenderMode 	
2 	xul.dll 	gfxWindowsPlatform::gfxWindowsPlatform 	gfx/thebes/gfxWindowsPlatform.cpp:219
3 	mozalloc.dll 	mozalloc.dll@0x106f 	
4 	xul.dll 	nsComponentManagerImpl::KnownModule::Load 	xpcom/components/nsComponentManager.cpp:973
5 	xul.dll 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:1948
6 	xul.dll 	nsComponentManagerImpl::CreateInstance 	xpcom/components/nsComponentManager.cpp:1225
7 	xul.dll 	CallCreateInstance 	obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:157
8 	xul.dll 	nsBaseWidget::BaseCreate 	widget/src/xpwidgets/nsBaseWidget.cpp:215
9 	xul.dll 	nsWindow::Create 	widget/src/windows/nsWindow.cpp:559
10 	xul.dll 	nsWebShellWindow::Initialize 	xpfe/appshell/src/nsWebShellWindow.cpp:219
11 	xul.dll 	nsAppShellService::JustCreateTopWindow 	xpfe/appshell/src/nsAppShellService.cpp:433
12 	xul.dll 	nsAppShellService::CreateHiddenWindow 	xpfe/appshell/src/nsAppShellService.cpp:182
13 	xul.dll 	nsAppStartup::CreateHiddenWindow 	toolkit/components/startup/src/nsAppStartup.cpp:160
14 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3623
15 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:128
16 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
17 	kernel32.dll 	BaseThreadInitThunk 	
18 	ntdll.dll 	__RtlUserThreadStart 	
19 	ntdll.dll 	_RtlUserThreadStart 	

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=gfxWindowsPlatform%3A%3AVerifyD2DDevice%28int%29

Comment 1

[Scoobidiver (away)]

It still happens in 8.0b1:
https://crash-stats.mozilla.com/report/list?signature=gfxWindowsPlatform%3A%3AVerifyD2DDevice%28int%29

Comment 2

[Scoobidiver (away)]

It happens with one or two GPUs.

Stack traces are now less buggy:
0 	xul.dll 	gfxWindowsPlatform::VerifyD2DDevice 	gfx/thebes/gfxWindowsPlatform.cpp:340
1 	xul.dll 	gfxWindowsPlatform::UpdateRenderMode 	
2 	xul.dll 	gfxWindowsPlatform::gfxWindowsPlatform 	gfx/thebes/gfxWindowsPlatform.cpp:193
3 	xul.dll 	gfxPlatform::Init 	gfx/thebes/gfxPlatform.cpp:268
4 	xul.dll 	gfxPlatform::GetPlatform 	gfx/thebes/gfxPlatform.cpp:233
5 	xul.dll 	ShouldUseImageSurfaces 	modules/libpr0n/src/imgFrame.cpp:113
6 	xul.dll 	imgFrame::Init 	modules/libpr0n/src/imgFrame.cpp:198
7 	xul.dll 	mozilla::imagelib::RasterImage::InternalAddFrame 	modules/libpr0n/src/RasterImage.cpp:851
8 	xul.dll 	mozilla::imagelib::RasterImage::EnsureFrame 	modules/libpr0n/src/RasterImage.cpp:989
9 	xul.dll 	mozilla::imagelib::nsGIFDecoder2::BeginImageFrame 	modules/libpr0n/decoders/nsGIFDecoder2.cpp:228
10 	xul.dll 	mozilla::imagelib::nsGIFDecoder2::WriteInternal 	modules/libpr0n/decoders/nsGIFDecoder2.cpp:956
11 	xul.dll 	mozilla::imagelib::RasterImage::WriteToDecoder 	modules/libpr0n/src/RasterImage.cpp:2284
12 	xul.dll 	mozilla::imagelib::RasterImage::AddSourceData 	modules/libpr0n/src/RasterImage.cpp:1254
13 	xul.dll 	mozilla::imagelib::RasterImage::WriteToRasterImage 	modules/libpr0n/src/RasterImage.cpp:2822
14 	xul.dll 	nsPipeInputStream::ReadSegments 	xpcom/io/nsPipe3.cpp:799
15 	xul.dll 	imgRequest::OnDataAvailable 	modules/libpr0n/src/imgRequest.cpp:1177
16 	xul.dll 	ProxyListener::OnDataAvailable 	modules/libpr0n/src/imgLoader.cpp:2101
17 	xul.dll 	nsJARChannel::OnDataAvailable 	modules/libjar/nsJARChannel.cpp:934
18 	xul.dll 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:510

Comment 3

[Bas Schouten (:bas.schouten)]

For the new stack that's an interesting crash, line 340 suggests this factory creation failed. This probably happens on some odd combination of circumstances. The comments seem to be non-English languages so I wonder if that's related.

We could alleviate the latter stack trace probably just by not ignoring the result of the create factory call and bailing out on failure.

Comment 4

[Scoobidiver (away)]

It's now #9 top crasher in 8.0.
It's correlated to the iZ3D driver (http://www.iz3d.com/):
  100% (657/659) vs.   1% (708/95929) S3DInjector.dll
         16% (105/659) vs.   0% (107/95929) 1.0.151.3131
          9% (58/659) vs.   0% (58/95929) 1.0.151.3154
         51% (339/659) vs.   0% (351/95929) 1.0.151.3214
          1% (4/659) vs.   0% (4/95929) 1.0.151.3332
          1% (8/659) vs.   0% (8/95929) 1.0.151.3382
          1% (5/659) vs.   0% (5/95929) 1.0.151.3563
         19% (124/659) vs.   0% (132/95929) 1.0.151.3659
          1% (8/659) vs.   0% (8/95929) 1.0.151.3907
          1% (6/659) vs.   0% (25/95929) 1.0.151.4016

Comment 5

[Sheila Mooney]

So this is not new but much higher for 8.0. Is there something we should be doing here? Was some new driver released that is causing these crashes?

Comment 6

[Joe Drew (not getting mail)]

Bas, let's do what you suggested in comment 3 and bail out on failure.

Comment 7

[Sheila Mooney]

Sitting in the #31 spot for FF8.0.1 and it's a start-up crash. It's a bit lower on the list for 8.0.

Comment 8

[Bas Schouten (:bas.schouten)]

Attachment: Deal with DXGI factory creation failure

Comment 9

[Joe Drew (not getting mail)]

Comment on attachment 588385 [details] [diff] [review]
Deal with DXGI factory creation failure

Why not just if (FAILED(hr))?

(Feel free to reflag if there's a reason.)

Comment 10

[Joe Drew (not getting mail)]

Maybe you meant to write "if (FAILED(hr) || !factory1)"?

Comment 11

[Bas Schouten (:bas.schouten)]

Comment on attachment 588385 [details] [diff] [review]
Deal with DXGI factory creation failure

Review of attachment 588385 [details] [diff] [review]:
-----------------------------------------------------------------

That is what I meant to write! Sorry :(

Comment 12

[Joe Drew (not getting mail)]

Comment on attachment 588385 [details] [diff] [review]
Deal with DXGI factory creation failure

Review of attachment 588385 [details] [diff] [review]:
-----------------------------------------------------------------

What did you mean to write? What I wrote, or what is in this patch?

If you meant to write what's in this patch, how about you just say if (FAILED(hr)) { return; } ?

Comment 13

[Bas Schouten (:bas.schouten)]

(In reply to Joe Drew (:JOEDREW!) from comment #12)
> Comment on attachment 588385 [details] [diff] [review]
> Deal with DXGI factory creation failure
> 
> Review of attachment 588385 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> What did you mean to write? What I wrote, or what is in this patch?
> 
> If you meant to write what's in this patch, how about you just say if
> (FAILED(hr)) { return; } ?

I meant to write what you wrote. Do you want me to upload a new patch? :P

Comment 14

[Joe Drew (not getting mail)]

consider this comment an r+ on that changed patch

Comment 15

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c654ab313a6d

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c654ab313a6d