854820 - crash in nsDisplayOpacity::GetType with AMD Radeon HD 6290/6310/6320/6470/7310/7340

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[Scoobidiver (away)]

It first showed up in 21.0a2/20130325 and is already #5 top browser crasher in 21.0a2. In case it has a meaning, the regression range is:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=749b9043312b&tochange=286f3ec182e8
Bug 714320 which is the same kind of crashes started in 22.0a1/20130325105600. Its regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3acbf951b3b1&tochange=4d3250f3afea
There are no patches in common.

Signature 	nsDisplayOpacity::GetType() More Reports Search
UUID	7ac53e7c-e270-4623-98ea-4687a2130326
Date Processed	2013-03-26 07:48:09
Uptime	542
Last Crash	1.4 hours before submission
Install Age	7.0 hours since version was first installed.
Install Time	2013-03-26 00:46:09
Product	Firefox
Version	21.0a2
Build ID	20130325042013
Release Channel	aurora
OS	Windows NT
OS Version	6.2.9200
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 20 model 2 stepping 0
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x6f0a82c6
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9809, AdapterSubsysID: 397f17aa, AdapterDriverVersion: 8.982.6.0
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ 
Processor Notes 	sp-processor01.phx1.mozilla.com_5314:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x9809
Total Virtual Memory	4294836224
Available Virtual Memory	3684122624
System Memory Use Percentage	53
Available Page File	2359279616
Available Physical Memory	784797696

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsDisplayOpacity::GetType 	layout/base/nsDisplayList.h:2297
1 	xul.dll 	mozilla::FrameLayerBuilder::AddThebesDisplayItem 	layout/base/FrameLayerBuilder.cpp:2422
2 	xul.dll 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	layout/base/FrameLayerBuilder.cpp:2245
3 	mozalloc.dll 	moz_xrealloc 	memory/mozalloc/mozalloc.cpp:86
4 	xul.dll 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	layout/base/FrameLayerBuilder.cpp:2084
5 	xul.dll 	mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems 	layout/base/FrameLayerBuilder.cpp:2084
6 	xul.dll 	mozilla::`anonymous namespace'::ContainerState::ContainerState 	layout/base/FrameLayerBuilder.cpp:264
7 	kernel32.dll 	TlsFreeStub 	
8 		@0xb7a6890

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsDisplayOpacity%3A%3AGetType%28%29

Comment 1

[Alex Keybl [:akeybl]]

Milan/Benjamin - who would be in the best position to investigate? Sounds like this may be any combination of:

A) Build-specific gfx tickling issue that coincidentally happened across FF22/21 on the same day
B) An external driver change
C) A recent change in FF21/22

B/C would likely need to combined, since FF20 is unaffected. For B, can we try to get a driver correlation and URLs KaiRo?

I'd suggest against requesting internal QA to start the investigation, given how difficult these issues have been to reproduce

Comment 2

[Scoobidiver (away)]

(In reply to Alex Keybl [:akeybl] from comment #1)
> A) Build-specific gfx tickling issue that coincidentally happened across
> FF22/21 on the same day
It seems so because there are no crashes in 21.0a2/20130326 for this bug and in 22.0a1/20130326 for bug 714320. It is gone as quickly as it appeared.

Comment 3

[Robert Kaiser]

(In reply to Scoobidiver from comment #2)
> (In reply to Alex Keybl [:akeybl] from comment #1)
> > A) Build-specific gfx tickling issue that coincidentally happened across
> > FF22/21 on the same day
> It seems so

In that case, no info needed from me. Also, getting driver correlations is really hard, I think bjacob known some good commands to get them if we really need them - and URLs aren't really interesting. A lot of Facebook, a bit of YouTube.