Closed Bug 902349 Opened 11 years ago Closed 11 years ago

crash in nsStyleSet::FileRules with AMD Radeon HD 6310

Categories

(Core :: Layout, defect)

23 Branch
x86
Windows 7
defect
Not set
blocker

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox23 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

It's currently #3 top crasher in 23.0 meaning this build is a bad build regarding bug 772330.
A new build with the same scope or including patches for important issues must be spin.

Signature 	@0x0 | EnumRulesMatching<ElementRuleProcessorData> More Reports Search
UUID 	4b34f939-3325-4354-bdd4-13f542130807
Date Processed	2013-08-07 05:40:37.332994
Uptime	285
Last Crash	9366 seconds before submission
Install Age 	16442 since version was first installed.
Install Time 	2013-08-07 02:05:52
Product 	Firefox
Version 	23.0
Build ID 	20130730113002
Release Channel 	release
OS 	Windows NT
OS Version 	6.1.7601 Service Pack 1
Build Architecture 	x86
Build Architecture Info 	AuthenticAMD family 20 model 1 stepping 0 | 2
Crash Reason 	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address 	0x0
User Comments 	This new update is terrible, it crashes on every website i go to. Please fix it asap.
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9804, AdapterSubsysID: 05201025, AdapterDriverVersion: 8.792.0.0
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 

Frame 	Module 	Signature 	Source
0 		@0x0 	
1 	xul.dll 	EnumRulesMatching<ElementRuleProcessorData> 	layout/style/nsStyleSet.cpp
2 	xul.dll 	nsStyleSet::FileRules(bool (*)(nsIStyleRuleProcessor *,void *),RuleProcessorData *,mozilla::dom::Element *,nsRuleWalker *) 	layout/style/nsStyleSet.cpp
3 	xul.dll 	nsStyleSet::ResolveStyleFor(mozilla::dom::Element *,nsStyleContext *,TreeMatchContext &) 	layout/style/nsStyleSet.cpp
4 	xul.dll 	PL_DHashTableOperate 	obj-firefox/xpcom/build/pldhash.cpp
5 	xul.dll 	xul.dll@0x2c3e10 	
6 		@0xd466400

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=RuleHash%3A%3AEnumerateAllRules%28mozilla%3A%3Adom%3A%3AElement*%2C+ElementDependentRuleProcessorData*%2C+NodeMatchContext%26%29
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=%400x0+|+EnumRulesMatching%3CElementRuleProcessorData%3E
We're still gathering feedback from 23 and considering a 23.0.1 for bug 901527 but we're throttled now so we should be able to stabilize the level of crashes on this bug for now until the new release is ready.
We are starting to see increasing levels of complains around this issue on SUMO.
Thanks Tyler !

I am checking on crash-stats on how many unique users may actually be impacted by this which the generally our data point to see how fast we have to react to this situation and as of now I see ~780 installations.Going by that number and our past experience with this RADEON crasher, I think we could still wait for the dot release involving other drivers/ride-along play along next week.

https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-08-09&signature=%400x0+|+EnumRulesMatching%3CElementRuleProcessorData%3E&version=Firefox%3A23.0

In addition, I am also needinfo'ing :Kairo/:tracy to keep an eye on this and keep this bug updated if the volume/unique users impacted changes.
Flags: needinfo?(twalker)
Flags: needinfo?(kairo)
To be clear, for those not looking at the dependencies; this is yet another instance of bug 772330, which Benjamin believes is an AMD driver bug, but which AMD won't let us speak to an engineer at their end about without steps to reproduce.  (Benjamin has a plan for some further kernel debugging that he can do the week after next that might help, though.)
And note that that also implies that simply rebuilding the build is likely to fix it, since this is specific to some (perhaps PGO-dependent) characteristic of the build.
Actually, traffic on release drivers makes me think that we did a build 2 just in case we hit this issue (email from hwine, dated "Thu, 01 Aug 2013 19:41:58 -0700").  Is that the case?  Can we switch to it or is it too late now that we've shipped build 1?
Flags: needinfo?(hwine)
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #6)
> Actually, traffic on release drivers makes me think that we did a build 2
> just in case we hit this issue (email from hwine, dated "Thu, 01 Aug 2013
> 19:41:58 -0700").  Is that the case?  Can we switch to it or is it too late
> now that we've shipped build 1?

It's too late now that we've shipped. Next thing to ship needs a completely different version number (e.g. 23.0.1). We only have the option to use the just-in-case build prior to QA signoff.
Flags: needinfo?(hwine)
We tried to reproduce this crash on the netbook which reproduced the previous Radeon issues (it has a Radeon HD 6310) but were unable to reproduce *this* crash. As such it's going to be impossible for QA to manually verify this is fixed.
The best we can do, now that we've shipped 23.0.1 is confirm this is no longer occurring in high volume on the newer release. Will leave the tracking nom set so we come back to check on this.
So far, data of 23.0.1 looks good in this regard, I don't see any crashes in high volume that look like they would come from this issue.
Flags: needinfo?(kairo)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
we're aware of this and will always be keeping an eye out as we can.
Flags: needinfo?(twalker)
You need to log in before you can comment on or make changes to this bug.