768383 - crash in nsFrameManager::ReResolveStyleContext mainly with AMD Radeon HD 6xxx series

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Scoobidiver (away)]

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...

Comment 2

[Alex Keybl [:akeybl]]

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).

Comment 3

[Alex Keybl [:akeybl]]

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.

Comment 4

[Scoobidiver (away)]

(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).

Comment 5

[Benjamin Smedberg]

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

Comment 6

[Scoobidiver (away)]

(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)

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Scoobidiver (away)]

There are 3 crashes in 14.0b10.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

(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.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 11

[Scoobidiver (away)]

(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.

Comment 12

[Benjamin Smedberg]

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.