It's #11 top browser crasher in the first hours of 14.0b9 while only #691 in 14.0b8. It's likely related to bug 714320 which also spiked. The Beta regression range is: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=f8d3886db65a&tochange=d050090e578c Signature nsTransitionManager::StyleContextChanged(mozilla::dom::Element*, nsStyleContext*, nsStyleContext*) More Reports Search UUID 8ff944fb-7b84-4a35-a280-84e202120626 Date Processed 2012-06-26 05:26:07 Uptime 33 Last Crash 1.3 minutes before submission Install Age 4.5 minutes since version was first installed. Install Time 2012-06-26 05:21:08 Product Firefox Version 14.0 Build ID 20120624012213 Release Channel beta OS Windows NT OS Version 6.1.7600 Build Architecture x86 Build Architecture Info AuthenticAMD family 20 model 1 stepping 0 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x9804, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.860.0.0 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility True Adapter Vendor ID 0x1002 Adapter Device ID 0x9804 Total Virtual Memory 2147352576 Available Virtual Memory 1876348928 System Memory Use Percentage 39 Available Page File 2478833664 Available Physical Memory 1052139520 Frame Module Signature Source 0 xul.dll nsTransitionManager::StyleContextChanged layout/style/nsTransitionManager.cpp:254 1 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1321 2 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1615 3 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1615 ... 21 xul.dll nsFrameManager::ComputeStyleChangeFor layout/base/nsFrameManager.cpp:1706 22 xul.dll mozilla::css::RestyleTracker::DoProcessRestyles layout/base/RestyleTracker.cpp:242 23 xul.dll nsCSSFrameConstructor::ProcessPendingRestyles layout/base/nsCSSFrameConstructor.cpp:11632 24 xul.dll PresShell::FlushPendingNotifications layout/base/nsPresShell.cpp:4004 25 xul.dll nsStaticCaseInsensitiveNameTable::Lookup xpcom/ds/nsStaticNameTable.cpp:250 26 xul.dll nsComputedDOMStyle::GetPropertyCSSValue layout/style/nsComputedDOMStyle.cpp:499 27 xul.dll nsComputedDOMStyle::GetPropertyValue layout/style/nsComputedDOMStyle.cpp:322 28 xul.dll nsComputedDOMStyle::GetPropertyValue layout/style/nsComputedDOMStyle.cpp:267 29 xul.dll nsIDOMCSS2Properties_Get obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:6879 30 xul.dll nsIDOMCSS2Properties_GetHeight obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:7569 31 mozjs.dll js::Shape::get js/src/jsscopeinlines.h:295 32 mozjs.dll js_NativeGet js/src/jsobj.cpp:4976 33 mozjs.dll js::NativeGet js/src/jsinterpinlines.h:168 34 mozjs.dll js::GetPropertyOperation js/src/jsinterpinlines.h:253 35 mozjs.dll js::Interpret js/src/jsinterp.cpp:2654 36 mozjs.dll WrapForSameCompartment js/src/jscompartment.cpp:184 37 mozjs.dll js::RunScript js/src/jsinterp.cpp:467 38 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:535 39 mozjs.dll js::Invoke js/src/jsinterp.cpp:567 40 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5419 41 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:1893 42 xul.dll nsCycleCollectingAutoRefCnt::incr obj-firefox/dist/include/nsISupportsImpl.h:161 43 user32.dll CalcWakeMask 44 xul.dll PeekUIMessage widget/windows/nsAppShell.cpp:102 More reports at: https://crash-stats.mozilla.com/report/list?signature=nsTransitionManager%3A%3AStyleContextChanged%28mozilla%3A%3Adom%3A%3AElement*%2C+nsStyleContext*%2C+nsStyleContext*%29 https://crash-stats.mozilla.com/report/list?signature=nsStyleContext%3A%3ACalcStyleDifference%28nsStyleContext*%29

The three crash signatures have all in common nsFrameManager::ReResolveStyleContext in the first frames. With combined signatures, it's currently #2 top crasher in 14.0b9. More reports at: https://crash-stats.mozilla.com/report/list?signature=nsFrameManager%3A%3AReResolveStyleContext%28nsPresContext*%2C+nsIFrame*%2C+nsIContent*%2C+nsStyleChangeList*%2C+nsChangeHint%2C+nsRestyleHint%2C+mozilla%3A%3Acss%3A%3ARestyleTracker%26%2C+nsFrameManager%3A%3ADesiredA11yNotifications%2C+nsTArray%3CnsIContent*%2C+nsTArrayDefaultAllocator%3E%26%2C+Tr...

May be bug 686335. If this explosiveness continues in b10 (going to build today), we may need to consider backing that change out for b11 (going to build on Tuesday).

Can we get a correlation report and URLs in the meantime? If this is related to plugins, it would be good to know which were in use at the time.

(In reply to Alex Keybl [:akeybl] from comment #2) > May be bug 686335. If it is, bug 714320 (appears randomly) and bug 768560 are also a regression from this bug. (In reply to Alex Keybl [:akeybl] from comment #3) > Can we get a correlation report and URLs in the meantime? If this is related > to plugins, it would be good to know which were in use at the time. There are no clear correlations (only Windows DLLs).

How did this bug get associated with AMD Radeon cards? I don't see the connection made in the bug comments.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > How did this bug get associated with AMD Radeon cards? I don't see the > connection made in the bug comments. Before I filed the bug, I had checked manually crash reports as there are no correlation files based on device and vendor IDs. The three signatures are correlated to those AMD GPUs (0x98.. device ID)

bz and I dived into the minidump from comment 0, and we're stumped. Given the callstack, "aElement" at the entry of nsTransitionManager::StyleContextChanged *can't* be null, because it's null-checked immediately before at http://hg.mozilla.org/releases/mozilla-beta/annotate/d050090e578c/layout/base/nsFrameManager.cpp#l735 So unless this is PGO-fail, or a device driver is clobbering the ECX register during execution, or something is clobbering stack memory, there is no logical way for this crash to occur. I think we should watch this is b10 to see if PGO effects change it.

There are 3 crashes in 14.0b10.

(In reply to Scoobidiver from comment #8) > There are 3 crashes in 14.0b10. Scoobidiver, please don't untrack bugs that have had tracking set to + for a particular revision. Release management goes through tracked bugs and decides if we're still going to track something or not and if you do this for us you take away our ability to know the whole picture. I'm happy to see that this crash has drastically declined for beta 10 and of course we won't track as long as the crashes stay very low but it's really important that you let us make that call. Thank you for being on top of the data, and for regular updates to crash bugs.

[Triage comment] Untracking since crash volume seems significantly decreased in 14 beta 10.

(In reply to Lukas Blakk [:lsblakk] from comment #9) > Scoobidiver, please don't untrack bugs that have had tracking set to + for a > particular revision. That's why I haven't set the tracking flag to --- but to ? in order for release drivers to reevaluate the tracking. It's something that is done regularly by other people.

Bug 772330 has a more general report about these random per-build crashes, but it's clear that this has gone away after b9, so resolving.