1375151 - Crash in nvwgf2um.dll | CContext::RelocateVideoFuncs

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-d2082f94-fa23-43a3-8716-9017a0170620.
=============================================================
Crashing Thread (7)
Frame 	Module 	Signature 	Source
Ø 0 	nvwgf2um.dll 	nvwgf2um.dll@0x653f 	
Ø 1 	nvwgf2um.dll 	nvwgf2um.dll@0x726d2 	
2 	d3d11.dll 	CContext::RelocateVideoFuncs() 	
3 	d3d11.dll 	CContext::RemoveContext(long) 	
4 	d3d11.dll 	CContext::UMPerformAmortizedProcessing_(D3D10DDI_HRTCORELAYER) 	
Ø 5 	nvwgf2um.dll 	nvwgf2um.dll@0xf928 	
Ø 6 	nvwgf2um.dll 	nvwgf2um.dll@0xf3f71 	
Ø 7 	nvwgf2um.dll 	nvwgf2um.dll@0xf3685 	
Ø 8 	nvwgf2um.dll 	nvwgf2um.dll@0x1ca34e 	
Ø 9 	nvwgf2um.dll 	nvwgf2um.dll@0x6ef2 	
Ø 10 	nvwgf2um.dll 	nvwgf2um.dll@0xc68b0 	
11 	d3d11.dll 	NDXGI::CDevice::DestroyDriverInstance() 	
12 	d3d11.dll 	CBridgeImpl<ILayeredUseCounted, ID3D11LayeredUseCounted, CLayeredObject<CContext> >::LUCBeginLayerDestruction() 	
13 	d3d11.dll 	CContext::DeleteCLS() 	
14 	d3d11.dll 	CUseCountedObject<NOutermost::CDeviceChild>::UCDestroy() 	
15 	d3d11.dll 	CUseCountedObject<NOutermost::CDeviceChild>::LUCDeferDeletion(int) 	
16 	d3d11.dll 	CBridgeImpl<ILayeredLockOwner, ID3D11LayeredDevice, CLayeredObject<CDevice> >::LLOBeginLayerDestruction() 	
17 	d3d11.dll 	CBridgeImpl<ILayeredLockOwner, ID3D11LayeredDevice, CLayeredObject<CDevice> >::LLOBeginLayerDestruction() 	
18 	d3d11.dll 	NDXGI::CDevice::LLOBeginLayerDestruction() 	
19 	d3d11.dll 	CBridgeImpl<ILayeredLockOwner, ID3D11LayeredDevice, CLayeredObject<NDXGI::CDevice> >::LLOBeginLayerDestruction() 	
20 	d3d11.dll 	NOutermost::CDevice::LLOBeginLayerDestruction() 	
21 	d3d11.dll 	TComObject<NOutermost::CDevice>::`scalar deleting destructor'(unsigned int) 	
22 	d3d11.dll 	_aulldiv 	
23 	xul.dll 	mozilla::layers::D3D11TextureData::`scalar deleting destructor'(unsigned int) 	
24 	xul.dll 	mozilla::layers::DestroyTextureData 	gfx/layers/client/TextureClient.cpp:248
25 	xul.dll 	mozilla::layers::TextureChild::ActorDestroy(mozilla::ipc::IProtocol::ActorDestroyReason) 	gfx/layers/client/TextureClient.cpp:259
26 	xul.dll 	mozilla::layers::PTextureChild::DestroySubtree(mozilla::ipc::IProtocol::ActorDestroyReason) 	obj-firefox/ipc/ipdl/PTextureChild.cpp:170
27 	xul.dll 	mozilla::layers::PTextureChild::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PTextureChild.cpp:123
28 	xul.dll 	mozilla::layers::PVideoBridgeChild::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PVideoBridgeChild.cpp:177
29 	xul.dll 	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 	ipc/glue/MessageChannel.cpp:2043
30 	xul.dll 	mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message&&) 	ipc/glue/MessageChannel.cpp:1969
31 	xul.dll 	mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) 	ipc/glue/MessageChannel.cpp:1838
32 	xul.dll 	mozilla::ipc::MessageChannel::MessageTask::Run() 	ipc/glue/MessageChannel.cpp:1871
33 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1428
34 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/threads/nsThreadUtils.cpp:472
35 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:368
36 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:311
37 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:291
38 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:503
39 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
40 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
41 	ucrtbase.dll 	_o__CIpow 	
42 	kernel32.dll 	BaseThreadInitThunk 	
43 	mozglue.dll 	patched_BaseThreadInitThunk 	mozglue/build/WindowsDllBlocklist.cpp:849
44 	ntdll.dll 	__RtlUserThreadStart 	
45 	ntdll.dll 	_RtlUserThreadStart

reports with this signature are regressing in volume after 55.0a1 build 20170420030346. this is the changelog to the build before: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0ea5ed7f91a6be996a4a3c5ab25e2cdf6b4377e&tochange=27311156637f9b5d4504373967e01c4241902ae7

all the reports come from windows 8 installations.

Adapter device id facet
1 	0x0641 	49 	27.53 %
2 	0x0a65 	46 	25.84 %
3 	0x0dea 	37 	20.79 %
4 	0x0fc6 	30 	16.85 %
5 	0x124b 	13 	7.30 %
6 	0x0a60 	1 	0.56 %
7 	0x0fd5 	1 	0.56 %
8 	0x107d 	1 	0.56 %

Adapter driver version facet
1 	9.18.13.1070 	49 	27.53 %
2 	9.18.13.286 	46 	25.84 %
3 	9.18.13.614 	43 	24.16 %
4 	9.18.13.1090 	37 	20.79 %
5 	9.18.13.1166 	1 	0.56 %
6 	9.18.13.1422 	1 	0.56 %
7 	9.18.13.637 	1 	0.56 %

Comment 1

[Marco Castelluccio [:marco]]

All the crashes in this signature have this gfx error:
(100.0% in signature vs 00.30% overall) GFX_ERROR "Failed to OpenSharedResource for SyncObjectD3D11: " = true

Comment 2

[Mike Taylor [:miketaylr]]

 Milan, something to be concerned about for 55?

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

David, is the spike related to bug 1345735, perhaps only because the signature moved from elsewhere?

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

It looks like the driver is crashing while we try to free resources after a TDR. In this case it's probably best to let the GPU process crash than try to figure out how to recover cleanly.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Didn't realize these were GPU process crashes.  So, yeah, that's what it's there to do (among other things), crash and save the browser from doing it instead.
:miketaylr, we're good here.

Comment 6

[Mike Taylor [:miketaylr]]

Thanks!

Comment 7

[[:philipp]]

half of the reports on 55.0b appear to be browser process crashes though...

Comment 8

[[:philipp]]

this is the #24 top browser crash in beta 6, accounting for 0.6% of all browser process crashes - are we really good here?^

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to [:philipp] from comment #7)
> half of the reports on 55.0b appear to be browser process crashes though...

I'll take a look.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

This looks like a special case of crashes in NDXGI::CDevice::DestroyDriverInstance (see bug 1292311 where we blocklisted a bunch of Nvidia drivers without really knowing the cause.)  Some of these are shutdown crashes, but the user reports here are usually about watching video.
Bas, can we dig through this a bit more, is there anything that we can check before calling mozilla::layers::DestroyTextureData to verify that things are good, more locking or something?  This is not exclusive to Nvidia, but it could be timing, or perhaps different run time capabilities reported, so discrete cards end up in this code more.

Comment 11

[Bas Schouten (:bas.schouten)]

There's DeviceRemoval messages in the metadata for this crash, but we haven't detected it yet. I bet that's related to why it blows up.

Comment 12

[Marcia Knous [:marcia]]

Currently #8 browser crash in 55.0.2 with 337 installs/640 crashes.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Bas, anything we can do to nudge this?

Comment 14

[Bas Schouten (:bas.schouten)]

This is not a race condition, none of the other threads is actually doing anything that appears connected to D3D. At the same time it's interesting that there's been a device reset, but it's not particularly useful. Since this is the destructor of an object (an object that's obviously valid since most of the destruction stack makes sense), there's also not a lot we can 'validly' do to prevent this crash as far as I can tell, even if we were able to predict its occurrence the only obvious solution would be leaking the object.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.