Carsten Book [:Tomcat] Reporter
	Description • 13 years ago

Found during looking at crashstats -   [@ nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint, nsRestyleHint, mozilla::css::RestyleTracker&, nsFrameManager::DesiredA11yNotifications, nsTArray<nsIContent*, nsTArrayDefaultAllocator>&, Tr... ] 

example report here: https://crash-stats.mozilla.com/report/index/3278d4ee-5e88-4df8-aa11-089ae2111204

and overview here: https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-12-05&signature=nsFrameManager%3A%3AReResolveStyleContext%28nsPresContext*%2C%20nsIFrame*%2C%20nsIContent*%2C%20nsStyleChangeList*%2C%20nsChangeHint%2C%20nsRestyleHint%2C%20mozilla%3A%3Acss%3A%3ARestyleTracker%26%2C%20nsFrameManager%3A%3ADesiredA11yNotifications%2C%20nsTArray%3CnsIContent*%2C%20nsTArrayDefaultAllocator%3E%26%2C%20Tr...&version=Firefox%3A9.0b4

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x309f98 	
1 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
2 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
3 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
4 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
5 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
6 	xul.dll 	nsFrameManager::ReResolveStyleContext 	
7 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
8 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
9 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
10 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
11 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
12 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
13 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
14 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
15 	xul.dll 	nsFrameManager::ReResolveStyleContext 	
16 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
17 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
18 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
19 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
20 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
21 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
22 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
23 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1548
24 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
25 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
26 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
27 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
28 	xul.dll 	nsFrameManager::ReResolveStyleContext 	layout/base/nsFrameManager.cpp:1569
29 	xul.dll 	nsFrameManager::ComputeStyleChangeFor 	layout/base/nsFrameManager.cpp:1655
30 	xul.dll 	mozilla::css::RestyleTracker::ProcessRestyles 	layout/base/RestyleTracker.cpp:240
31 	xul.dll 	nsCSSFrameConstructor::ProcessPendingRestyles 	layout/base/nsCSSFrameConstructor.cpp:11631
32 	xul.dll 	PresShell::FlushPendingNotifications 	layout/base/nsPresShell.cpp:3981
33 	xul.dll 	PresShell::WillPaint 	layout/base/nsPresShell.cpp:6813
34 	xul.dll 	nsViewManager::CallWillPaintOnObservers 	view/src/nsViewManager.cpp:1580
35 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:878
36 		@0x80 	
37 	xul.dll 	nsCycleCollectingAutoRefCnt::decr 	obj-firefox/dist/include/nsISupportsImpl.h:211

	Scoobidiver (away)
	Comment 1 • 13 years ago

It's #154 top crasher in 8.0.1, #45 in 9.0b4, and #247 in 10.0a2.

It first appeared in 7.0a1/20110528.

It's probably a dupe of bug 637121 where its crash signature stopped after 6.0.2.

Here are some comments:
"Doing a mouseover that makes a tooltip div visible"
"Crash occurs on opening Firebug"
"Using firebug to set pixel width of a div. Accidently typed in four decimal places or precision (eg 66.6667). Browser crashed instantly."
"using css3 column width property, browser crashes when window is resized and then refreshed"

	Bob Clary [:bc] (inactive)
	Comment 2 • 13 years ago

1. http://www.trondheimcalling.no/
2. Crash

Beta/10, Aurora/11 Linux, Mac, Windows

Nightly/12 on 20111223 crashed but a current Nightly does not. 

bp-df2a3880-1c18-48d9-986a-51bb62120106
bp-372edf37-1cdd-4c58-af14-d22f62120106
bp-85732959-4639-413c-a2c4-36afe2120106
bp-296450fd-ec27-47ce-8610-4ede12120106
bp-b8f43b0e-38fc-4086-b049-f23912120106

	Bob Clary [:bc] (inactive)
	Comment 3 • 13 years ago

Automation can reproduce the crash with the url in Beta/11 on Mac but no where else. It does appear to still be a minor issue in Socorro on Windows Aurora/12, Nighlty/13 with a couple of crashes in late February.

	Mats Palmgren (inactive)
	Comment 4 • 12 years ago

I can reproduce the crash in a mozilla-release (Fx12) debug build, but not -esr10
nor -beta.  There were some changes for abs.pos. children in column-set in that
time frame, iirc.

	Mats Palmgren (inactive)
	Comment 5 • 12 years ago

The frame marked in green color has a bunch of placeholder children with a
NULL out-of-flow.  We crash on the first of those, marked red.

	Mats Palmgren (inactive)
	Comment 6 • 12 years ago

I suspect this is a null-pointer crash.  It would be nice to know what fixed it though.

	Scoobidiver (away)
	Comment 7 • 12 years ago

There are crashes across every versions, 70% happening on Windows XP.
It's #122 top browser crasher in 11.0, #103 in 12.0, #140 in 13.0b2, #171 in 14.0a2, and #83 in 15.0a1.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsFrameManager%3A%3AReResolveStyleContext%28nsPresContext*%2C%20nsIFrame*%2C%20nsIContent*%2C%20nsStyleChangeList*%2C%20nsChangeHint%2C%20nsRestyleHint%2C%20mozilla%3A%3Acss%3A%3ARestyleTracker%26%2C%20nsFrameManager%3A%3ADesiredA11yNotifications%2C%20nsTArray%3CnsIContent*%2C%20nsTArrayDefaultAllocator%3E%26%2C%20Tr...

	Mats Palmgren (inactive)
	Comment 8 • 12 years ago

We only have one nsFrameManager::ReResolveStyleContext method really, so querying
only the name gives a more complete picture:
https://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&range_value=1&range_unit=weeks&query_search=signature&query_type=contains&query=nsFrameManager%3A%3AReResolveStyleContext&do_query=1

There can be many different bugs leading up to a crash there.  It just means that
something is badly wrong in the frame tree.  I still suspect that the reason
http://www.trondheimcalling.no/ crashes may have been fixed in Fx13.  Maybe we
can verify that by finding the first nightly that doesn't crash on that URL.

	(no longer active)
	Comment 9 • 12 years ago

(In reply to Mats Palmgren [:mats] from comment #4)
> I can reproduce the crash in a mozilla-release (Fx12) debug build, but not
> -esr10
> nor -beta.  There were some changes for abs.pos. children in column-set in
> that
> time frame, iirc.

Hmm, I would suspect bug 724978 is the fix here, but that patch has not landed on ESR yet...

	Mats Palmgren (inactive)
	Comment 10 • 12 years ago

Correction: I *do* crash on -esr10.  Sorry for the confusion.

Applying the branch patch in bug 724978 on esr10 does not fix it and the crash 
looks the same, so it seems some other change is also needed...

	Mats Palmgren (inactive)
	Comment 11 • 12 years ago

Perhaps that missing other change is what caused the orange and backout
of bug 724978 on esr10?

	(no longer active)
	Comment 12 • 12 years ago

Could be, yes.  We need somebody to bisect here.

	Bob Clary [:bc] (inactive)
	Comment 13 • 12 years ago

started getting additional signatures @ mozilla::layout::FrameChildListIterator::FrameChildListIterator nsFrameManager::CaptureFrameState ... on Aurora/15 and Nightly/16. Note this is all platforms and both 32 and 64 bit. I'll see about a regression range...

	Bob Clary [:bc] (inactive)
	Comment 14 • 12 years ago

Assuming you can trust my bisection, it seems this regressed:

Program received signal SIGSEGV, Segmentation fault.
0x0134313a in nsIFrame::GetContent (this=0x0) at /work/mozilla/builds/beta/mozilla/layout/base/../generic/nsIFrame.h:696

Found regression between 20120612135425-20120613212925
Pushlog: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=271b0e7e0728&tochange=87ec2429df24
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-13-mozilla-beta-debug/firefox-14.0.en-US.debug-linux-i686.tar.bz2
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-14-mozilla-beta-debug/firefox-14.0.en-US.debug-linux-i686.tar.bz2

Program received signal SIGSEGV, Segmentation fault.
0x01350a8a in nsIFrame::GetContent (this=0x0) at /work/mozilla/builds/aurora/mozilla/layout/base/../generic/nsIFrame.h:673

Found regression between 20120612212826-20120613182724
Pushlog: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=8a3042764de7&tochange=c9aa071bf2fd
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-13-mozilla-aurora-debug/firefox-15.0a2.en-US.debug-linux-i686.tar.bz2
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-14-mozilla-aurora-debug/firefox-15.0a2.en-US.debug-linux-i686.tar.bz2

Program received signal SIGSEGV, Segmentation fault.
0x0135f6f4 in nsIFrame::GetContent (this=0x0) at /work/mozilla/builds/nightly/mozilla/layout/base/../generic/nsIFrame.h:684

Found regression between 20120612182724-20120613231623
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=964b11fea7f1&tochange=3f408698a03f
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-13-mozilla-central-debug/firefox-16.0a1.en-US.debug-linux-i686.tar.bz2
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-14-mozilla-central-debug/firefox-16.0a1.en-US.debug-linux-i686.tar.bz2

bug 764354 is common to each range. dbaron, does that make sense?

	Scott Johnson (:jwir3)
	Comment 15 • 12 years ago

(In reply to Bob Clary [:bc:] from comment #14)
> Assuming you can trust my bisection, it seems this regressed:
> bug 764354 is common to each range. dbaron, does that make sense?

Unlikely. It's more likely that bug 733614 was the regression, because this backed out changes made in bug 695222, and, due to a failing crashtest, bug 724978 was backed out as well (see bug 724978, comment 57).

	Thomasy
	Comment 16 • 12 years ago

(In reply to Scott Johnson (:jwir3) from comment #15)
> (In reply to Bob Clary [:bc:] from comment #14)
> > Assuming you can trust my bisection, it seems this regressed:
> > bug 764354 is common to each range. dbaron, does that make sense?
> 
> Unlikely. It's more likely that bug 733614 was the regression, because this
> backed out changes made in bug 695222, and, due to a failing crashtest, bug
> 724978 was backed out as well (see bug 724978, comment 57).
I use mozregression. I get the result below.
The first bad revision is:
changeset:    96570:aeaa00b5cab5
使用者:        Scott Johnson <sjohnson@mozilla.com>
日期:        Wed Jun 13 11:00:56 2012 -0500
提交摘要:    Bug 733614: Backout changes from bug 695222 for mozilla 16 branch [r=dbaron].
Regression found using mozcommitbuilder 0.4.10 on linux2 at 2012-10-24 18:36:39
I find one slightly different between patch and backed out patch
https://bug733614.bugzilla.mozilla.org/attachment.cgi?id=632424
https://bug695222.bugzilla.mozilla.org/attachment.cgi?id=582956
https://hg.mozilla.org/mozilla-central/rev/aeaa00b5cab5#l6.12
 bool isBalancing = colStyle->mColumnFill == NS_STYLE_COLUMN_FILL_BALANCE;  
if (isBalancing) {
    
The backed out version wont't check whether it is Balancing or not (isBalancing)

	Alice0775 White
	Comment 17 • 12 years ago

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/60e86b847759
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929122038
Crash:
http://hg.mozilla.org/mozilla-central/rev/af3668a89015
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929141938
Pushlog;
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=60e86b847759&tochange=af3668a89015

In local build
Last good: 34f184d2a6f8
First bad: 00f422b2cf36

Triggered by: 
	00f422b2cf36	Ehsan Akhgari — Bug 10209 - Part 6: Implement the CSS "containing block" concept correctly as a binary relation, as opposed to a unary relation; r=bzbarsky

	Thomasy
	Comment 18 • 12 years ago

(In reply to Alice0775 White from comment #17)
> Regression window(m-c)
> Good:
> http://hg.mozilla.org/mozilla-central/rev/60e86b847759
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
> ID:20110929122038
> Crash:
> http://hg.mozilla.org/mozilla-central/rev/af3668a89015
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
> ID:20110929141938
> Pushlog;
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=60e86b847759&tochange=af3668a89015
> 
> In local build
> Last good: 34f184d2a6f8
> First bad: 00f422b2cf36
> 
> Triggered by: 
> 	00f422b2cf36	Ehsan Akhgari — Bug 10209 - Part 6: Implement the CSS
> "containing block" concept correctly as a binary relation, as opposed to a
> unary relation; r=bzbarsky


The version above will not crash at the first load. But it will crash after press shift + refresh. Any idea?

	Alice0775 White
	Comment 19 • 12 years ago

What is press shift + refresh ?

I tried to reproduce the crash with Good builds
i.e.m-c tinderbox build(http://hg.mozilla.org/mozilla-central/rev/60e86b847759
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929122038)
And local build from 34f184d2a6f8

Shift+Click reload button : I cannot reproduce the crash 
Click reload button: I cannot reproduce the crash
Ctrl+F5: I cannot reproduce the crash
F5: I cannot reproduce the crash


I cannot reproduce the crash in both builds.

	Thomasy
	Comment 20 • 12 years ago

(In reply to Alice0775 White from comment #19)
> What is press shift + refresh ?
>
> I tried to reproduce the crash with Good builds
> i.e.m-c tinderbox
> build(http://hg.mozilla.org/mozilla-central/rev/60e86b847759
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
> ID:20110929122038)
> And local build from 34f184d2a6f8
>
> Shift+Click reload button : I cannot reproduce the crash
> Click reload button: I cannot reproduce the crash
> Ctrl+F5: I cannot reproduce the crash
> F5: I cannot reproduce the crash
>
>
> I cannot reproduce the crash in both builds.

I mean Shift+Click reload button.

It crash both on my Linux 64bit and Linux 32bit(Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0) machine and Win7 64bit machine

I use the version from mozregression

>$ mozregression --good=2012-09-28 --bad=2012-09-30
>
>Downloading nightly from 2012-09-29
>
>Starting nightly

	Alice0775 White
	Comment 21 • 12 years ago

(In reply to Thomasy from comment #20)
> 
> I mean Shift+Click reload button.
> 
> It crash both on my Linux 64bit and Linux 32bit(Mozilla/5.0 (X11; Linux
> i686; rv:18.0) Gecko/18.0 Firefox/18.0) machine and Win7 64bit machine
> 
> I use the version from mozregression
> 
> >$ mozregression --good=2012-09-28 --bad=2012-09-30
> >
> >Downloading nightly from 2012-09-29
> >
> >Starting nightly

So, did you mean ?
Nightly2012-09-28 7f4867717226: not crash
Nightly2012-09-30 b5b082d183d0: crash with Shift+Click reload button.

How about Nightly2012-09-29 cb4b93331e4f?

	Scoobidiver (away)
	Comment 22 • 12 years ago

It doesn't crash for me.

	Thomasy
	Comment 23 • 12 years ago

Try this testcase

	Thomasy
	Comment 24 • 12 years ago

:Scoobidiver
It the testcase can crash both on Linux and Windows for today's Nightly.

	Scoobidiver (away)
	Comment 25 • 12 years ago

Indeed, the testcase crashes Nightly on Windows, and also changes my French Nightly into an Akan one (Crash reporter is in Akan).

The need info flag was for comment 21.

	Thomasy
	Comment 26 • 12 years ago

(In reply to Alice0775 White from comment #21)
> (In reply to Thomasy from comment #20)
> > 
> > I mean Shift+Click reload button.
> > 
> > It crash both on my Linux 64bit and Linux 32bit(Mozilla/5.0 (X11; Linux
> > i686; rv:18.0) Gecko/18.0 Firefox/18.0) machine and Win7 64bit machine
> > 
> > I use the version from mozregression
> > 
> > >$ mozregression --good=2012-09-28 --bad=2012-09-30
> > >
> > >Downloading nightly from 2012-09-29
> > >
> > >Starting nightly
> 
> So, did you mean ?
> Nightly2012-09-28 7f4867717226: not crash
> Nightly2012-09-30 b5b082d183d0: crash with Shift+Click reload button.
> 
> How about Nightly2012-09-29 cb4b93331e4f?

It crashes for Nightly2012-09-29.

	cyril
	Comment 27 • 11 years ago

Crashes on 19.0.2 (release)

	Mats Palmgren (inactive)
	Comment 28 • 11 years ago

WFM on Linux64.  This might have been fixed by recent improvements for abs.pos.
support in columns.

	Alice0775 White
	Comment 29 • 11 years ago

Still crash
bp-69e935c9-4ed5-44bf-8743-7e8bb2130403
http://hg.mozilla.org/releases/mozilla-beta/rev/2e91ff229d84
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 ID:20130401192816

But not
http://hg.mozilla.org/releases/mozilla-aurora/rev/6f40920a3968
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130403 Firefox/22.0 ID:20130403004013
http://hg.mozilla.org/mozilla-central/rev/97cfc16ba5dc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130403 Firefox/23.0 ID:20130403030841


Fixed window(m-c)
Crash:
http://hg.mozilla.org/mozilla-central/rev/f4394e306dad
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130319 Firefox/22.0 ID:20130319104713
Fixed:
http://hg.mozilla.org/mozilla-central/rev/126563fd3ba1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130319 Firefox/22.0 ID:20130319134513
Fixed pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4394e306dad&tochange=126563fd3ba1

Fixed window(m-i)
Crash:
http://hg.mozilla.org/integration/mozilla-inbound/rev/750ceb3d7faa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130319 Firefox/22.0 ID:20130319072616
Fixed:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9e6e38d4ae0b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130319 Firefox/22.0 ID:20130319080217
Fixed pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=750ceb3d7faa&tochange=9e6e38d4ae0b

I guess this was fixed by:
  2ed966e4fa58	Scott Johnson — Bug 600100, Part 1: Return a status of NS_FRAME_NOT_COMPLETE during reflow of nsBlockFrame if we have a next continuation with pushed floats to prevent crashing in columns. [r=dbaron]

	Mats Palmgren (inactive)
	Comment 30 • 11 years ago

Thanks Alice, I'm going to resolve this as fixed by bug 600100 then.
tracking-firefox21? should go in that bug.

	Tracy Walker [:tracy]
	Comment 31 • 11 years ago

There are still reports of this on 21 (betas), 22a (nightlies) and 23a (nightlies) since the noted fix.

However, I cannot reproduce with the given test case on 23a of 20130422 on Mac nor Win 7