Closed Bug 1375151 Opened 4 years ago Closed 2 months ago

Crash in nvwgf2um.dll | CContext::RelocateVideoFuncs


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

55 Branch
Windows 8



Tracking Status
firefox55 --- fix-optional
firefox56 --- fix-optional
firefox57 --- fix-optional


(Reporter: philipp, Assigned: bas.schouten, NeedInfo)



(Keywords: crash, regression, Whiteboard: [gfx-noted])

Crash Data

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/
37 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/
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:

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 	49 	27.53 %
2 	46 	25.84 %
3 	43 	24.16 %
4 	37 	20.79 %
5 	1 	0.56 %
6 	1 	0.56 %
7 	1 	0.56 %
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
 Milan, something to be concerned about for 55?
Flags: needinfo?(milan)
David, is the spike related to bug 1345735, perhaps only because the signature moved from elsewhere?
Flags: needinfo?(milan) → needinfo?(dvander)
See Also: → 1345735
Whiteboard: [gfx-noted]
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.
Flags: needinfo?(dvander)
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.
half of the reports on 55.0b appear to be browser process crashes though...
this is the #24 top browser crash in beta 6, accounting for 0.6% of all browser process crashes - are we really good here?^
Flags: needinfo?(milan)
(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.
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.
Flags: needinfo?(milan) → needinfo?(bas)
See Also: → 1292311
Assignee: nobody → bas
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.
Flags: needinfo?(bas)
Currently #8 browser crash in 55.0.2 with 337 installs/640 crashes.
Bas, anything we can do to nudge this?
Flags: needinfo?(bas)
Priority: P3 → P2
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.
Flags: needinfo?(bas)
Flags: needinfo?(milan)
Moving to p3 because no activity for at least 1 year(s).
See for more information
Priority: P2 → P3

Closing because no crashes reported for 12 weeks.

Closed: 2 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.