395012 - Crash [@ nsFrameIterator::GetFirstChildInner] with iframes, position: absolute, direction: rtl

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase which crashes current trunk build normally within 500ms.
You need to have caret browsing enabled (F7) and the testcase uses enhanced privileges, so you need to download it to your computer to see the crash.

This seems to have regressed between 2007-04-13 and 2007-04-17:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-04-13+04&maxdate=2007-04-17+07&cvsroot=%2Fcvsroot
(Ria, do you have builds in between to get a more precise regression range? Thanks!)

http://crash-stats.mozilla.com/report/index/c965c626-5bb4-11dc-a906-001a4bd43ed6
0  	nsFrameIterator::GetFirstChildInner(nsIFrame*)  	 mozilla/layout/base/nsFrameTraversal.cpp:502
1 	nsFrameIterator::GetFirstChild(nsIFrame*) 	mozilla/layout/base/nsFrameTraversal.cpp:441
2 	nsFrameIterator::Next() 	mozilla/layout/base/nsFrameTraversal.cpp:329
3 	nsIFrame::GetFrameFromDirection(nsDirection, int, int, int, nsIFrame**, int*, int*) 	mozilla/layout/generic/nsFrame.cpp:5073
4 	nsFrameSelection::GetPrevNextBidiLevels(nsIContent*, unsigned int, nsFrameSelection::HINT, int) 	mozilla/layout/generic/nsSelection.cpp:2000
5 	nsFrameSelection::GetPrevNextBidiLevels(nsIContent*, unsigned int, int) 	mozilla/layout/generic/nsSelection.cpp:1956
6 	nsCaret::GetCaretFrameForNodeOffset(nsIContent*, int, nsFrameSelection::HINT, unsigned char, nsIFrame**, int*) 	mozilla/layout/base/nsCaret.cpp:669
7 	nsCaret::DrawAtPositionWithHint(nsIDOMNode*, int, nsFrameSelection::HINT, unsigned char, int) 	mozilla/layout/base/nsCaret.cpp:575
8 	nsCaret::DrawCaret(int) 	mozilla/layout/base/nsCaret.cpp:971
9 	nsCaret::StartBlinking() 	mozilla/layout/base/nsCaret.cpp:542
10 	nsCaret::SetCaretVisible(int) 	mozilla/layout/base/nsCaret.cpp:227

Comment 1

[Martijn Wargers (dead)]

Or clicking in the iframe in the online testcase is working too to get the crash.
(if you download the testcase, then do a "Right-click Save Link Target As...")

Comment 2

[Martijn Wargers (dead)]

Ok, Ria gave me a more precise regression range between 2007-04-13 22 and 2007-04-14 22:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-04-13+20&maxdate=2007-04-14+23&cvsroot=%2Fcvsroot
I guess this is a regression of bug 144000, then.

Comment 3

[Uri Bernstein]

This is the stack trace I'm getting in a debug build:

#0  0x0eb6e908 in nsCachedStyleData::GetStyleDisplay (this=0xddddddf9) at /Users/uri/mozilla/trunk/mozilla/layout/style/nsStyleStructList.h:95
#1  0x0e312d04 in nsStyleContext::GetStyleDisplay (this=0xdddddddd) at /Users/uri/mozilla/trunk/mozilla/layout/style/nsStyleStructList.h:95
#2  0x0ead9d18 in nsIFrame::GetStyleDisplay (this=0x247b1d4) at ../../dist/include/layout/nsStyleStructList.h:95
#3  0x0e144a18 in nsFrameIterator::IsPopupFrame (this=0x34089d10, aFrame=0x247b1d4) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsFrameTraversal.cpp:551
#4  0x0e144c60 in nsFrameIterator::GetNextSibling (this=0x34089d10, aFrame=0x247b3e8) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsFrameTraversal.cpp:476
#5  0x0e1452fc in nsFrameIterator::Next (this=0x34089d10) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsFrameTraversal.cpp:324
#6  0x0e1bea04 in nsIFrame::GetFrameFromDirection (this=0x247b3e8, aDirection=eDirNext, aVisual=0, aJumpLines=0, aScrollViewStop=1, aOutFrame=0xbfff89e0, aOutOffset=0xbfff89e4, aOutJumpedLine=0xbfff89e8) at /Users/uri/mozilla/trunk/mozilla/layout/generic/nsFrame.cpp:5073
#7  0x0e21d6dc in nsFrameSelection::GetPrevNextBidiLevels (this=0x34007970, aNode=0x34009370, aContentOffset=1, aHint=HINTLEFT, aJumpLines=0) at /Users/uri/mozilla/trunk/mozilla/layout/generic/nsSelection.cpp:2000
#8  0x0e21db04 in nsFrameSelection::GetPrevNextBidiLevels (this=0x34007970, aNode=0x34009370, aContentOffset=1, aJumpLines=0) at /Users/uri/mozilla/trunk/mozilla/layout/generic/nsSelection.cpp:1956
#9  0x0e123c68 in nsCaret::GetCaretFrameForNodeOffset (this=0x326bfad0, aContentNode=0x34009370, aOffset=1, aFrameHint=HINTLEFT, aBidiLevel=0 '\0', aReturnFrame=0xbfff8bec, aReturnOffset=0xbfff8bf0) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCaret.cpp:669
#10 0x0e1246d4 in nsCaret::DrawAtPositionWithHint (this=0x326bfad0, aNode=0x3400938c, aOffset=1, aFrameHint=HINTLEFT, aBidiLevel=0 '\0', aInvalidate=1) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCaret.cpp:575
#11 0x0e124d88 in nsCaret::DrawCaret (this=0x326bfad0, aInvalidate=1) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCaret.cpp:971

What happens is that the nsPlaceholderFrame for the first iframe is pointing to a deleted frame as its mOutOfFlowFrame. The deleted frame is passed by nsFrameIterator::GetNextSibling to nsFrameIterator::IsPopupFrame().

I also get the following warnings and assertions before crashing, although I'm not sure they're relevant:

GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/style/nsCSSStyleSheet.cpp, line 1519
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(result)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1857
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1955
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/style/nsCSSStyleSheet.cpp, line 1519
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(result)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1857
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1955
###!!! ASSERTION: no user stylesheets in styleset, but we have one!: 'numBefore > 0', file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1823
###!!! ASSERTION: no user stylesheets in styleset, but we have one!: 'numBefore > 0', file /Users/uri/mozilla/trunk/mozilla/layout/base/nsPresShell.cpp, line 1823
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!

I'll continue investigating when I have time, although at this point I'm pretty sure that this is not directly caused by 144000, but rather that that fix exposed an older bug.

Comment 4

[Uri Bernstein]

Attachment: simpler testcase

This testcase doesn't have bidi and doesn't require reloading (although it still requires caret browsing to be enabled, and running locally. It also requires the window to be focused when loaded).

The crash here is at a slightly different place, but it's the same underlying problem, which becomes evident when looking deeper into the stack:

#0  0x0e0f2628 in nsCSSFrameConstructor::FindFrameWithContent (this=0x33616300, aFrameManager=0x2347c1c, aParentFrame=0x2429adc, aParentContent=0x336b8960, aContent=0x336d2980, aHint=0x0) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp:10704
#1  0x0e0f687c in nsCSSFrameConstructor::FindPrimaryFrameFor (this=0x33616300, aFrameManager=0x2347c1c, aContent=0x336d2980, aFrame=0xbfffbffc, aHint=0x0) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp:10796
[...]
#8  0x0e124f10 in nsCaret::StartBlinking (this=0x2b09c700) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCaret.cpp:542
[...]
#13 0x0e4b288c in nsEventStateManager::ResetBrowseWithCaret (this=0x326a4150) at /Users/uri/mozilla/trunk/mozilla/content/events/src/nsEventStateManager.cpp:5303
#14 0x0e4b67ac in nsEventStateManager::PreHandleEvent (this=0x326a4150, aPresContext=0x3220f980, aEvent=0xbfffcd3c, aTargetFrame=0x0, aStatus=0xbfffcabc, aView=0x33d33e20) at /Users/uri/mozilla/trunk/mozilla/content/events/src/nsEventStateManager.cpp:984
[...]
#17 0x0e665750 in nsViewManager::HandleEvent (this=0x33617160, aView=0x33d33e20, aPoint=@0xbfffcb64, aEvent=0xbfffcd3c, aCaptured=0) at /Users/uri/mozilla/trunk/mozilla/view/src/nsViewManager.cpp:1292
#18 0x0e66688c in nsViewManager::DispatchEvent (this=0x33617160, aEvent=0xbfffcd3c, aStatus=0xbfffcc7c) at /Users/uri/mozilla/trunk/mozilla/view/src/nsViewManager.cpp:1248
[...]
#24 0x0bd0b6c0 in nsChildView::TearDownView (this=0x33d28a10) at /Users/uri/mozilla/trunk/mozilla/widget/src/cocoa/nsChildView.mm:491
#25 0x0bd158c0 in nsChildView::Destroy (this=0x33d28a10) at /Users/uri/mozilla/trunk/mozilla/widget/src/cocoa/nsChildView.mm:558
#26 0x0e659228 in nsView::~nsView (this=0x33d289b0) at /Users/uri/mozilla/trunk/mozilla/view/src/nsView.cpp:255
[...]
#36 0x0e1c3ed4 in nsSubDocumentFrame::Destroy (this=0x2429bfc) at /Users/uri/mozilla/trunk/mozilla/layout/generic/nsFrameFrame.cpp:586
[...]
#40 0x0e1c59b0 in nsFrameList::DestroyFrame (this=0x24299a8, aFrame=0x2429adc) at /Users/uri/mozilla/trunk/mozilla/layout/generic/nsFrameList.cpp:162
[...]
#43 0x0e1401d4 in nsFrameManager::RemoveFrame (this=0x2347c1c, aParentFrame=0x2429958, aListName=0x2010adc, aOldFrame=0x2429adc) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsFrameManager.cpp:690
#44 0x0e1111b8 in nsCSSFrameConstructor::ContentRemoved (this=0x33616300, aContainer=0x29fb200, aChild=0x336b8960, aIndexInContainer=1, aInReinsertContent=0) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp:9509
#45 0x0e10e7dc in nsCSSFrameConstructor::RecreateFramesForContent (this=0x33616300, aContent=0x336b8960) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp:11075
#46 0x0e10eeac in nsCSSFrameConstructor::RestyleElement (this=0x33616300, aContent=0x336b8960, aPrimaryFrame=0x2429adc, aMinHint=0) at /Users/uri/mozilla/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp:9940
[...]

So, as part of restyling the body, the IFrame, and therefore its view, are destroyed. This causes the main View to receive a GOTFOCUS event, which, in turn, causes the caret to be re-displayed - while the frame is in mid-destruction.

I suspect the weak link here (where this chain should be broken) is the call from frame #14 to #13, but I don't understand what's going on well enough to know how to fix it.

Comment 5

[Martijn Wargers (dead)]

Ok, this has become worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100304 Minefield/3.0a9pre

Comment 6

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).