Closed Bug 902349 Opened 8 years ago Closed 8 years ago
crash in ns
Style Set::File Rules with AMD Radeon HD 6310
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.
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?
(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.
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
we're aware of this and will always be keeping an eye out as we can.
You need to log in before you can comment on or make changes to this bug.