1329451 - Crash in @0x0 | CDXGISwapChain::EmulateDirtyRectPresentVistaBlt

Status: RESOLVED WORKSFORME

(External Software Affecting Firefox :: Other, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-c44631c4-5d4e-4724-b528-8174e2170107.
=============================================================
Crashing Thread (21)
Frame 	Module 	Signature 	Source
0 		@0x0 	
1 	dxgi.dll 	CDXGISwapChain::EmulateDirtyRectPresentVistaBlt(tagRECT const*, unsigned int, tagRECT*, SUBRESOURCE_BLT_MAP const*, unsigned __int64) 	
2 	dxgi.dll 	DXGIContractHr<DXGIContract<Valid<0>, Valid<2289696769>, Valid<2289696772>, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp, NoOp> >::operator long() 	
3 	dxgi.dll 	CDXGISwapChain[::IDXGISwapChain1]::Present1(unsigned int, unsigned int, DXGI_PRESENT_PARAMETERS const*) 	
4 	xul.dll 	mozilla::layers::CompositorD3D11::EndFrame() 	gfx/layers/d3d11/CompositorD3D11.cpp:1135
5 	xul.dll 	mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) 	gfx/layers/composite/LayerManagerComposite.cpp:994
6 	xul.dll 	mozilla::layers::LayerManagerComposite::UpdateAndRender() 	gfx/layers/composite/LayerManagerComposite.cpp:483
7 	xul.dll 	mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/composite/LayerManagerComposite.cpp:404
8 	xul.dll 	mozilla::gfx::VRManager::NotifyVsync(mozilla::TimeStamp const&) 	gfx/vr/VRManager.cpp:157
9 	xul.dll 	mozilla::detail::RunnableMethodImpl<void ( SoftwareDisplay::*)(mozilla::TimeStamp), 1, 1, mozilla::TimeStamp>::Run() 	obj-firefox/dist/include/nsThreadUtils.h:768
10 	xul.dll 	MessageLoop::RunTask(already_AddRefed<mozilla::Runnable>) 	ipc/chromium/src/base/message_loop.cc:346
11 	xul.dll 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask&&) 	ipc/chromium/src/base/message_loop.cc:354
12 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc:429
13 	xul.dll 	base::MessagePumpForUI::DoRunLoop() 	ipc/chromium/src/base/message_pump_win.cc:212
14 	xul.dll 	base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpWin::Dispatcher*) 	ipc/chromium/src/base/message_pump_win.cc:56
15 	xul.dll 	base::MessagePumpWin::Run(base::MessagePump::Delegate*) 	ipc/chromium/src/base/message_pump_win.h:80
16 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:225
17 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:205
18 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc:180
19 	xul.dll 	`anonymous namespace'::ThreadFunc 	ipc/chromium/src/base/platform_thread_win.cc:28
20 	kernel32.dll 	BaseThreadInitThunk 	
21 	ntdll.dll 	__RtlUserThreadStart 	
22 	ntdll.dll 	_RtlUserThreadStart

this is a crash signature that is exclusive to firefox 32 bit on windows 8/8.1 - most of the crash comments are in spanish...
correlations show that this is most likely related to a module "sgfxu32.dll" belonging to SMSC Core Graphics Software - should we try to attempt some sort of blacklisting based on that?

Correlations for Firefox Beta
(100.0% in signature vs 00.08% overall) Module "sgfxu32.dll" = true
(100.0% in signature vs 01.67% overall) Module "mfnetcore.dll" = true
(100.0% in signature vs 02.19% overall) platform_version = 6.2.9200
(100.0% in signature vs 02.22% overall) platform_pretty_version = Windows 8
(100.0% in signature vs 04.74% overall) Module "mfcore.dll" = true
(100.0% in signature vs 11.90% overall) address = 0x0
(93.22% in signature vs 06.73% overall) reason = EXCEPTION_ACCESS_VIOLATION_EXEC
(100.0% in signature vs 20.24% overall) Module "MSAudDecMFT.dll" = true
(100.0% in signature vs 35.08% overall) Module "dui70.dll" = true
(100.0% in signature vs 35.18% overall) Module "duser.dll" = true
(98.31% in signature vs 32.86% overall) Module "xmllite.dll" = true
(98.31% in signature vs 34.65% overall) "D2D1.1+" in app_notes = true
(98.31% in signature vs 34.65% overall) "DWrite+" in app_notes = true
(98.31% in signature vs 34.67% overall) "DWrite?" in app_notes = true
(100.0% in signature vs 40.13% overall) "D3D11 Layers+" in app_notes = true
(100.0% in signature vs 40.14% overall) "D3D11 Layers?" in app_notes = true
(100.0% in signature vs 42.42% overall) Module "explorerframe.dll" = true
(98.31% in signature vs 37.76% overall) Module "d2d1.dll" = true
(88.14% in signature vs 24.39% overall) Module "winhttp.dll" = true
(81.36% in signature vs 21.20% overall) Module "wshbth.dll" = true
(52.54% in signature vs 04.12% overall) bios_manufacturer = Insyde
(44.07% in signature vs 03.33% overall) adapter_device_id = 0x0166
(50.85% in signature vs 10.33% overall) Module "ntasn1.dll" = true
(49.15% in signature vs 10.56% overall) Module "thumbcache.dll" = true
(38.98% in signature vs 06.80% overall) bios_manufacturer = Hewlett-Packard
(22.03% in signature vs 02.30% overall) cpu_microcode_version = 0x15
(22.03% in signature vs 02.49% overall) cpu_microcode_version = 0x28
(15.25% in signature vs 00.02% overall) adapter_subsys_id = 1946103c

  @0x0 | CDXGISwapChain::EmulateDirtyRectPresentVistaBlt|EXCEPTION_ACCESS_VIOLATION_EXEC (29 crashes)
    100% (29/29) vs.   0% (35/75587) sgfxu32.dll
          0% (0/29) vs.   0% (1/75587) 8.15.2.5
          3% (1/29) vs.   0% (2/75587) 9.18.4.0
          3% (1/29) vs.   0% (1/75587) 9.18.4.1
         31% (9/29) vs.   0% (11/75587) 9.18.5.1
         10% (3/29) vs.   0% (3/75587) 9.18.5.2
         52% (15/29) vs.   0% (17/75587) 9.18.5.3

Comment 1

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

Kip, is the fact that we're calling VRManager indicative of some non-default preference set?

Comment 2

[:kip (Kearwood Gilbert)]

(In reply to Milan Sreckovic [:milan] from comment #1)
> Kip, is the fact that we're calling VRManager indicative of some non-default
> preference set?

The VRManager entry point here is VRManager::NotifyVSync, which is being called once per vsync even with the dom.vr.enabled preference disabled.

When there are no VR devices enumerated (you can't enumerate any without dom.vr.enabled set), this function is intended to have no effect.

Please note that while investigating the performance regression in Bug 1325810, I noticed that VRManager::NotifyVSync will perform an IPC to the content process once per vsync even if there are no VR devices.  The receiving end does nothing in this case.  The proposed solution to Bug 1325810 is to eliminate that IPC call when not necessary.

Based on the stack trace for this bug; however, the thread stopped after the IPC call in VRManager::NotifyVSync.

tl;dr - The stack trace attached to this bug does not guarantee that the dom.vr.enabled preference is set, but also does not preclude it.

Comment 3

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 4

[:kip (Kearwood Gilbert)]

(In reply to Milan Sreckovic [:milan] from comment #1)
> Kip, is the fact that we're calling VRManager indicative of some non-default
> preference set?

Since bug 1325810 has landed, eliminating the extraneous IPC call, the reported call stacks are no longer including VRManager::NotifyVSync.  I am also not seeing any modules in the crash reports that correlate with WebVR usage (ie no Oculus or SteamVR runtime libraries).

I suspect that this crash may not be WebVR specific and could occur even without the dom.vr.enabled preference set.

Comment 5

[:kip (Kearwood Gilbert)]

There appears to be a very high correlation between this crash and sgfxu32.dll.  Some searches show that this dll is part of a USB graphics interface, commonly used in HP laptop docking stations (ie. HP 2005pr docking station).

Comment 6

[Jim Mathies [:jimm]]

based on crash volume.