Closed Bug 490193 Opened 12 years ago Closed 12 years ago

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

Categories

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

x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: fehe, Assigned: tnikkel)

References

()

Details

(Keywords: crash, regression, topcrash, Whiteboard: See Comments 7, 11, and 12)

Crash Data

Attachments

(2 files, 1 obsolete file)

37.03 KB, application/x-zip-compressed
Details
3.07 KB, text/plain
Details
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
Component: General → Layout: HTML Frames
Product: Firefox → Core
Version: unspecified → Trunk
NOTE: Place your mouse pointer in the first box labeled "Flash MP3 Players" before scrolling.
Forget scrolling. This link crashes the browser automatically: http://digg.com/d1papV

It looks like it has something to do with frames.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash on scroll on certain pages [@ nsLayoutUtils::GetCrossDocParentFrame(nsIFrame const*, nsPoint*) ] → Crash on certain pages with frames [@ nsLayoutUtils::GetCrossDocParentFrame(nsIFrame const*, nsPoint*) ]
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.
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?
Not only Win XP is affected, also Win 7 beta 32/64bit.
(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
Attached file Possible testcase (obsolete) —
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.
OS: Windows XP → All
QA Contact: general → layout.html-frames
Flags: wanted1.9.2?
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?
(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.
(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.
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.
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
Whiteboard: See Comments 7, 11, and 12
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
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.
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.
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Assignee: nobody → tnikkel
This happens intermittently on deviantART.com with a slightly different stack trace. See bp-2b9198d4-d37a-4d91-a221-b310b2090427
This test case will trigger the bug without additional user intervention.

Simply unzip then launch dept.asp.html.  The browser should crash.
Attachment #374675 - Attachment is obsolete: true
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.
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.
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.
(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.
@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
I use Nightly Build.
your Hourly ?
(In reply to comment #24)
> I use Nightly Build.
> your Hourly ?

Yes...
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
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Removed blocking1.9.1? per bug 490376, comment 9.
Flags: blocking1.9.1?
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.
Status: RESOLVED → VERIFIED
(In reply to comment #28)
> Removed blocking1.9.1? per bug 490376, comment 9.

Per bug 490376 comment 10, readding it.
Flags: blocking1.9.1?
Clearing noms, let's use bug 490376 for all that.
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Crash Signature: [@ nsLayoutUtils::GetCrossDocParentFrame(nsIFrame const*, nsPoint*) ]
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.