Open Bug 1405838 Opened 3 years ago Updated 2 years ago

Crash in igd10umd32.dll | CContext::ID3D11DeviceContext1_UpdateSubresource_Amortized<T>

Categories

(Core :: Graphics, defect, P3)

55 Branch
x86
Windows
defect

Tracking

()

Tracking Status
firefox-esr52 --- unaffected
firefox56 --- wontfix
firefox57 + wontfix
firefox58 --- fix-optional
firefox59 --- ?

People

(Reporter: philipp, Unassigned)

References

Details

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

Crash Data

This bug was filed from the Socorro interface and is 
report bp-a0422ca2-b1f2-447b-aef1-91c590170930.
=============================================================
Crashing Thread (30), Name: ImageBridgeChild
Frame 	Module 	Signature 	Source
Ø 0 	igd10umd32.dll 	igd10umd32.dll@0x191d5 	
Ø 1 	igd10umd32.dll 	igd10umd32.dll@0x7a47 	
Ø 2 	igd10umd32.dll 	igd10umd32.dll@0x7064 	
Ø 3 	igd10umd32.dll 	igd10umd32.dll@0x335f 	
4 	d3d11.dll 	CContext::ID3D11DeviceContext1_UpdateSubresource_Amortized<0>(ID3D11DeviceContext1*, ID3D11Resource*, unsigned int, D3D11_BOX const*, void const*, unsigned int, unsigned int) 	
5 	xul.dll 	mozilla::layers::IMFYCbCrImage::GetD3D11TextureData(mozilla::layers::PlanarYCbCrData, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>) 	gfx/layers/IMFYCbCrImage.cpp:184
6 	xul.dll 	mozilla::layers::IMFYCbCrImage::GetD3D11TextureClient(mozilla::layers::KnowsCompositor*) 	gfx/layers/IMFYCbCrImage.cpp:195
7 	xul.dll 	mozilla::layers::IMFYCbCrImage::GetTextureClient(mozilla::layers::KnowsCompositor*) 	gfx/layers/IMFYCbCrImage.cpp:227
8 	xul.dll 	mozilla::layers::ImageClientSingle::UpdateImage(mozilla::layers::ImageContainer*, unsigned int) 	gfx/layers/client/ImageClient.cpp:198
9 	xul.dll 	mozilla::layers::ImageBridgeChild::UpdateImageClient(RefPtr<mozilla::layers::ImageContainer>) 	gfx/layers/ipc/ImageBridgeChild.cpp:388
10 	xul.dll 	mozilla::runnable_args_memfn<RefPtr<mozilla::layers::ImageBridgeChild>, void ( mozilla::layers::ImageBridgeChild::*)(RefPtr<mozilla::layers::ImageContainer>), RefPtr<mozilla::layers::ImageContainer> >::Run() 	media/mtransport/runnable_utils.h:174
11 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc:535
12 	xul.dll 	base::MessagePumpDefault::Run(base::MessagePump::Delegate*) 	ipc/chromium/src/base/message_pump_default.cc:36
13 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:319
14 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:299
15 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc:181
16 	xul.dll 	`anonymous namespace'::ThreadFunc 	ipc/chromium/src/base/platform_thread_win.cc:28
17 	kernel32.dll 	BaseThreadInitThunk 	
18 	mozglue.dll 	patched_BaseThreadInitThunk 	mozglue/build/WindowsDllBlocklist.cpp:824
19 	ntdll.dll 	__RtlUserThreadStart 	
20 	ntdll.dll 	_RtlUserThreadStart

these crashes spike up in firefox 55 and seem to hit particular users repeatedly judging by the (sometimes angry) user comments.

Adapter device id facet
1 	0x2a42 	3420 	80.28 %
2 	0x2e22 	690 	16.20 %
3 	0x2e12 	123 	2.89 %
[Tracking Requested - why for this release]: Crashing bug while watching videos, very angry user comments from v56 users already.
Sotaro, anything that stands out from the stack that we can work around?  Jean-Yves, is this hardware that we're tracking with video problems?
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(jyavenard)
Priority: -- → P1
Whiteboard: [gfx-noted]
Keywords: regression
(In reply to Milan Sreckovic [:milan] from comment #2)
> Sotaro, anything that stands out from the stack that we can work around? 
> Jean-Yves, is this hardware that we're tracking with video problems?

It's different devices than those in bug 140511.
Flags: needinfo?(jyavenard)
See Also: → 1405110
There is a big increase in crash volume here too between 55.0.3 and 56.0. That could be the crash becoming more common in 56 or it  could be just a result of more users updating from 55.0.3 to 56.0.  Hard to tell. 
648 crashes in 480 installations in the last week in 56, wontfix for 56 as that is not a super high crash rate.   Is there something we can block in 57?
(In reply to Milan Sreckovic [:milan] from comment #2)
> Sotaro, anything that stands out from the stack that we can work around? 
> Jean-Yves, is this hardware that we're tracking with video problems?

It seems that we could add immediate context pointer check first.
Flags: needinfo?(sotaro.ikeda.g)
Depends on: 1407149
(In reply to Sotaro Ikeda [:sotaro] from comment #5)
> (In reply to Milan Sreckovic [:milan] from comment #2)
> > Sotaro, anything that stands out from the stack that we can work around? 
> > Jean-Yves, is this hardware that we're tracking with video problems?
> 
> It seems that we could add immediate context pointer check first.

Bug 1407149 is created for it.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #4)
> There is a big increase in crash volume here too between 55.0.3 and 56.0.
> That could be the crash becoming more common in 56 or it  could be just a
> result of more users updating from 55.0.3 to 56.0.  Hard to tell. 
> 648 crashes in 480 installations in the last week in 56, wontfix for 56 as
> that is not a super high crash rate.   Is there something we can block in 57?

Bug 1223270 might be related.
Why is the crash count going down?
probably due to the win64 migration - this particular signature is in a 32bit intel driver and i don't see any obvious corresponding issue that's hitting win64bit builds with the affected gpus.
Very small number of 64-bit crashes, you're right.
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.