Closed Bug 1300232 Opened 8 years ago Closed 7 years ago

Crash in igd10iumd32.dll | NDXGI::CDevice::Flush

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected
firefox51 --- affected
firefox52 --- wontfix

People

(Reporter: dbaron, Unassigned)

References

Details

(Keywords: crash, stale-bug, topcrash, Whiteboard: gfx-noted)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-00acb2ad-502b-47f2-9765-eb95a2160902.
=============================================================

There are a decent number of crashes with the signature igd10iumd32.dll | NDXGI::CDevice::Flush .  The stack for this one is:

0 	igd10iumd32.dll 	igd10iumd32.dll@0x2a2cf 	
Ø 1 	igd10iumd32.dll 	igd10iumd32.dll@0x3a026 	
Ø 2 	igd10iumd32.dll 	igd10iumd32.dll@0xb7573 	
3 	d3d11.dll 	NDXGI::CDevice::Flush(unsigned int, D3DWDDM2_0DDI_CONTEXTTYPE_FLAG) 	
4 	d3d11.dll 	NDXGI::CDevice::DXGIAcquireSync(IDXGIResourceInternal*, NDXGI::CKMResource*, unsigned __int64, unsigned long) 	
5 	d3d11.dll 	NDXGI::CResource::AcquireSync(unsigned __int64, unsigned long) 	
6 	xul.dll 	mozilla::layers::AutoLockTexture::AutoLockTexture(ID3D11Texture2D*) 	gfx/layers/IMFYCbCrImage.cpp:38
7 	xul.dll 	mozilla::layers::IMFYCbCrImage::GetTextureClient(mozilla::layers::CompositableClient*) 	gfx/layers/IMFYCbCrImage.cpp:263
8 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::ShiftData<nsTArrayInfallibleAllocator>(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) 	obj-firefox/dist/include/nsTArray-inl.h:272
9 	xul.dll 	mozilla::layers::ImageClientSingle::UpdateImage(mozilla::layers::ImageContainer*, unsigned int) 	gfx/layers/client/ImageClient.cpp:179
10 	xul.dll 	mozilla::layers::PImageBridgeChild::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PImageBridgeChild.cpp:736
11 	xul.dll 	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 	ipc/glue/MessageChannel.cpp:1654
12 	xul.dll 	mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) 	ipc/glue/MessageChannel.cpp:1595
13 	ntdll.dll 	NtWaitForSingleObject 	
14 	kernelbase.dll 	WaitForSingleObjectEx 	
15 	xul.dll 	mozilla::layers::UpdateImageClientNow 	gfx/layers/ipc/ImageBridgeChild.cpp:556
16 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc:444
17 	xul.dll 	`anonymous namespace'::ThreadFunc(void*) 	ipc/chromium/src/base/platform_thread_win.cc:26


Many of the URLs are https://www.facebook.com/ or youtube videos, which makes me think it might be related to DXVA, which is why I'm filing it in this component... although maybe it's just a regular graphics bug?
Component: Audio/Video: Playback → Graphics
Likely just need to be blacklisted.
Flags: needinfo?(nical.bugzilla)
Whiteboard: gfx-noted
Jean-Yves, do you mean blacklist for DXVA?
Flags: needinfo?(nical.bugzilla) → needinfo?(jyavenard)
I think so yes... whatever required to prevent those DLLs from crashing.
Flags: needinfo?(jyavenard)
Anthony, see comment 1
Component: Graphics → Audio/Video
Flags: needinfo?(ajones)
Component: Audio/Video → Audio/Video: Playback
Blacklisting seems reasonable at this point in time.
Flags: needinfo?(ajones)
Priority: -- → P1
Who can do it (the blocklisting)?

Also, are this and related crashes a 32-bit version of crash(es) in bug 1295075?  Based on the timing of the spike, probably not, but I thought I'd ask.
Flags: needinfo?(ajones)
Crash volume for signature 'igd10iumd32.dll | NDXGI::CDevice::Flush':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 3 crashes from 2016-09-19.
 - beta    (version 50): 83 crashes from 2016-09-20.
 - release (version 49): 470 crashes from 2016-09-05.
 - esr     (version 45): 875 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       0
 - aurora        2       1
 - beta         69      14
 - release     397      73
 - esr         101      84

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora  #1326     #873
 - beta    #234      #439
 - release #134      #366
 - esr     #121
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → affected
How many of the Flush ones are *not* from IMFYCbCrImage::GetTextureClient??
Chris - can you figure out what to do about this issue?
Flags: needinfo?(ajones) → needinfo?(cpearce)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #5)
> Blacklisting seems reasonable at this point in time.

Just had a look at some aggregations for this signature, and crashes happen on all sorts of Intel cards and driver versions. So unfortunately I don't think blacklisting would help here.
Crash volume for signature 'igd10iumd32.dll | NDXGI::CDevice::Flush':
 - nightly (version 54): 0 crashes from 2017-01-23.
 - aurora  (version 53): 0 crashes from 2017-01-23.
 - beta    (version 52): 32 crashes from 2017-01-23.
 - release (version 51): 235 crashes from 2017-01-16.
 - esr     (version 45): 3067 crashes from 2016-08-10.

Crash volume on the last weeks (Week N is from 02-06 to 02-12):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0
 - aurora        0       0
 - beta         20       7
 - release     161      31       0
 - esr         194     189     170     151     121      91     152

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly
 - aurora
 - beta    #706      #1529
 - release #371      #498
 - esr     #110
status-firefox52: --- → affected
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
Not sure what to do here... Someone who knows more about how gfx works should look into this...
Flags: needinfo?(cpearce)
(In reply to Chris Pearce (:cpearce) from comment #13)
> Not sure what to do here... Someone who knows more about how gfx works
> should look into this...

So, have we decided against blocklisting then, as suggested in some of the comments?
Flags: needinfo?(cpearce)
Sounds like blacklisting isn't possible.
Flags: needinfo?(cpearce) → needinfo?(ajones)
The "Process Type" in all the reports is blank which suggests that this is only happening in the non-e10s case
Flags: needinfo?(ajones)
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
From https://crash-stats.mozilla.com/signature/?signature=igd10iumd32.dll%20%7C%20NDXGI%3A%3ACDevice%3A%3AFlush&date=%3E%3D2017-09-17T10%3A25%3A54.000Z&date=%3C2017-10-17T10%3A25%3A54.000Z, I don't see any reports from 57 and 58 within one month. I am going to close this bug. Please feel free to reopen this bug if there is any crashes reported.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.