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?

Likely just need to be blacklisted.

Jean-Yves, do you mean blacklist for DXVA?

I think so yes... whatever required to prevent those DLLs from crashing.

Anthony, see comment 1

Blacklisting seems reasonable at this point in time.

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.

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

How many of the Flush ones are *not* from IMFYCbCrImage::GetTextureClient??

Chris - can you figure out what to do about this issue?

(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

Mass wontfix for bugs affecting firefox 52.

Not sure what to do here... Someone who knows more about how gfx works should look into this...

(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?

Sounds like blacklisting isn't possible.

The "Process Type" in all the reports is blank which suggests that this is only happening in the non-e10s case

Mass change P1->P2 to align with new Mozilla triage process

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.