490193 - Crash on certain pages with frames [@ nsLayoutUtils::GetCrossDocParentFrame(nsIFrame const*, nsPoint*) ]

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre

When scrolling on certain pages, the browser immediately crashes.

This is a regression from the 20090425 build a new topcrash: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6a1pre&platform=windows&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsLayoutUtils%3A%3AGetCrossDocParentFrame%28nsIFrame%20const*%2C%20nsPoint*%29

http://crash-stats.mozilla.com/report/index/76e3ea14-604a-43c9-a43c-a1b572090425

0  	xul.dll  	nsLayoutUtils::GetCrossDocParentFrame  	 layout/base/nsLayoutUtils.cpp:274
1 	xul.dll 	nsDisplayListBuilder::IsMovingFrame 	layout/base/nsDisplayList.h:191
2 	xul.dll 	AddItemsToRegion 	layout/base/nsLayoutUtils.cpp:1182


Reproducible: Always

Steps to Reproduce:
1. Visit the linked URL
2. Choose "English"
3. Hover the "Audio" menu and choose "Flash MP3 Players"
4. Wait for the page to load then mouseover and scroll with your scrollwheel.
5. Page should crash

Comment 1

[IU]

NOTE: Place your mouse pointer in the first box labeled "Flash MP3 Players" before scrolling.

Comment 2

[John]

Forget scrolling. This link crashes the browser automatically: http://digg.com/d1papV

It looks like it has something to do with frames.

Comment 3

[Daniel C]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre

http://crash-stats.mozilla.com/report/index/3298fbe0-b8c9-47f3-a9ae-03b682090426

I get this every time I read an inbox message on Facebook.

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

no matter how hard i try, i can't repro the crash on any of the given sites using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre ID:20090425043745

can somebody wrap up some testcase and/or find the regression range?

Comment 5

[Simek]

Not only Win XP is affected, also Win 7 beta 32/64bit.

Comment 6

[Peter van der Woude [:Peter6]]

(In reply to comment #4)
> no matter how hard i try, i can't repro the crash on any of the given sites
> using
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090425
> Minefield/3.6a1pre ID:20090425043745
> 
> can somebody wrap up some testcase and/or find the regression range?
Same here, can't get FF to crash.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre ID:20090426044401

Comment 7

[IU]

Attachment: Possible testcase

The crash is a bit harder to reproduce if you're not successful with the steps in Comment 0.  If your reflex is fast enough for your CPU speed, try this:

1. Unzip the file
2. Launch dept.asp.html, *BUT* before the page completely loads, very quickly scroll down the page down using your mouse wheel.

Comment 8

[Bill Gianopoulos [:WG9s]]

This crash appears to have a really high occurrence in crash reporter and those who can produce it seem to have little difficulty reproducing it.  However, others (including me) seem to be totally unable to reproduce the issues.  This lead me to believe it is most likely somehow extension related.

Could those who can actually reproduce this try to reproduce using a fresh profile or in safe mode?  And if this can not be reproduced under those conditions try to isolate what extension is the cause?

Comment 9

[IU]

(In reply to comment #8)
> lead me to believe it is most likely somehow extension related.
> 

Wrong assumption.

I can reproduce with a fresh install + profile using my steps in comment 7.

Other than that, I know no other way to help reproduce.  If someone has a better method, please post.

Comment 10

[Bill Gianopoulos [:WG9s]]

(In reply to comment #9)
> (In reply to comment #8)
> > lead me to believe it is most likely somehow extension related.
> > 
> 
> Wrong assumption.
> 
> I can reproduce with a fresh install + profile using my steps in comment 7.
> 
> Other than that, I know no other way to help reproduce.  If someone has a
> better method, please post.

Too bad.  I was hoping this was extension related.  That would have permitted me to isolate this to a particular changeset.  So now we have kind of a mystery as some people seem to be able to reproduce this at will while others (such as me) are unable to reproduce this using any of the steps to reproduce listed in this bug under Windows/XP, or under 32 or 64 bit Linux.

Comment 11

[John]

To those who cannot easily replicate this: you have to scroll as the page is loading/ before content appears. Once the page is completely loaded, it doesn't crash.

Comment 12

[Tony Chung [:tchung]]

I can reproduce this from comment 11 on trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre.   My str is:

1) login to www.evite.com
2) select an event that you might have stored
3) as the event page is loading, scroll up and down.   
4) crash with the same stacktrace as others are reporting.

http://crash-stats.mozilla.com/report/index/6fd72bc1-f3b2-4306-9d67-cf8682090426

Comment 13

[Bill Gianopoulos [:WG9s]]

Since I am unable to duplicate this issue, I can only use the information from the crashstats to determine a regression range, which is:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e9d9227f498&tochange=dfff608ebad0

From that list, and given the reported symptoms, a likely candidate would seem to be:

d56efd447561	Robert O'Callahan — Bug 384037. Eliminate nsFrameNavigator and switch XUL splitters to using nsFrameList instead. Also add a check so that we don't crash when a splitter's parent is not a XUL box. r+sr=dbaron

Comment 14

[Daniel C]

I can reproduce this every time as per comment 3, but not by using comment 0 or comment 2. I used the hourly archive to narrow this down to the following:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dfd65697f114&tochange=4d32e821e751

Hope this helps, we're up to nearly 6000 crashes over the last 3 days.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm almost certain that it's bug 485275.

tn, nsDisplaySolidColor's GetUnderlyingFrame returns null in some situations and that is probably causing this crash. We should give it the frame for the subdocument frame if the subdocument doesn't have its own root frame.

Comment 16

[Matthew Cline]

This happens intermittently on deviantART.com with a slightly different stack trace. See bp-2b9198d4-d37a-4d91-a221-b310b2090427

Comment 17

[IU]

Attachment: Reduced test case (with autoscroll added to trigger bug)

This test case will trigger the bug without additional user intervention.

Simply unzip then launch dept.asp.html.  The browser should crash.

Comment 18

[Marcia Knous [:marcia]]

I also get this crash consistently uploading pictures on flickr on the mac, so if you don't have an evite account you can try that.

Comment 19

[Matthew Cline]

Attachment: Crash C/C++ stack trace

Reproducing the deviantART.com variant of the bug with a debugging build, right before the crash I got:

    ###!!! ASSERTION: Must have an underlying frame for leaf item: 'f', file nsLayoutUtils.cpp, line 1180

With the crash's top three stack frames:

#0  0xb574b433 in nsIFrame::GetParent (this=0x0)
    at ./../../../generic/nsIFrame.h:722
#1  0xb578699a in nsLayoutUtils::IsProperAncestorFrameCrossDoc (
    aAncestorFrame=0xa4575880, aFrame=0x0, aCommonAncestor=0x0)
    at nsLayoutUtils.cpp:307
#2  0xb5766f72 in nsDisplayListBuilder::IsMovingFrame (this=0xbfcc4d08,
    aFrame=0x0) at ./../base/nsDisplayList.h:191

For frame #1, the relevant snippet of code is:

303       while (parentFrame != aCommonAncestor) {
304         if (parentFrame == aAncestorFrame)
305           return PR_TRUE;
306
307         parentFrame = GetCrossDocParentFrame(parentFrame);
308       }

With gdb showing:

(gdb) p parentFrame
$1 = (class nsIFrame *) 0x0
(gdb) p aCommonAncestor
$2 = (class nsIFrame *) 0x0
(gdb) p aAncestorFrame
$3 = (class nsIFrame *) 0xa4575880

Not sure why the while loop didn't bail, since aCommonAncestor and parentFrame were both NULL.

Comment 20

[Timothy Nikkel (:tnikkel)]

Thanks to everybody who provided help in tracking this down (testcases, backtraces, etc). The problem is understood now and the patch in bug 490376 will fix this bug when it gets checked in.

Comment 21

[pal-moz]

(In reply to comment #20)
> Thanks to everybody who provided help in tracking this down (testcases,
> backtraces, etc). The problem is understood now and the patch in bug 490376
> will fix this bug when it gets checked in.


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090430 Minefield/3.6a1pre ID:20090430041822

seems to be not fixed.
crash on below site, scroll while loading.

(In reply to comment #2)
> Forget scrolling. This link crashes the browser automatically:
> http://digg.com/d1papV
> 
> It looks like it has something to do with frames.

Comment 22

[pal-moz]

BP:
http://crash-stats.mozilla.com/report/index/39dfe4da-73b3-43d1-8172-ef3df2090430

Comment 23

[Jim Jeffery not reading bug-mail 1/2/11]

@pal-moz
I think you have a build too soon that has the patch, I don't crash on the link in comment 21 , I'm using buildID:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090430 Minefield/3.6a1pre Firefox/3.0.7 ID:20090430042612

Comment 24

[pal-moz]

I use Nightly Build.
your Hourly ?

Comment 25

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #24)
> I use Nightly Build.
> your Hourly ?

Yes...

Comment 26

[IU]

Fixed by bug 490376

Latest hourly builds have fix. Should be fixed in tomorrow's Nightly.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090430 Minefield/3.6a1pre ID:20090430070616

Comment 27

[Peter van der Woude [:Peter6]]

Win32:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1241090772-20090430042612-4561d478f6ba-firefox-3.6a1pre.en-US.win32.zip

Mac OSX:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-macosx/1241095029-20090430053709-373f39a2d1ec-firefox-3.6a1pre.en-US.mac.dmg

Linux:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-linux/1241086281-20090430031121-4561d478f6ba-firefox-3.6a1pre.en-US.linux-i686.tar.bz2

should be fixed

Comment 28

[Timothy Nikkel (:tnikkel)]

Removed blocking1.9.1? per bug 490376, comment 9.

Comment 29

[Marcia Knous [:marcia]]

Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090504 Minefield/3.6a1pre.

No longer getting the consistent crash uploading a picture to flickr.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #28)
> Removed blocking1.9.1? per bug 490376, comment 9.

Per bug 490376 comment 10, readding it.

Comment 31

[Benjamin Smedberg]

Clearing noms, let's use bug 490376 for all that.