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

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
11 years ago
6 years ago

People

(Reporter: martijn.martijn, Unassigned)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
x86
Windows XP
crash, regression, rtl, testcase
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Created attachment 279725 [details]
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
(Reporter)

Comment 1

11 years ago
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...")
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.
Flags: blocking1.9?
Created attachment 281219 [details]
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
(Reporter)

Comment 5

11 years ago
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
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9-
Resolution: --- → WORKSFORME
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

Comment 6

11 years ago
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
(Assignee)

Updated

8 years ago
Crash Signature: [@ nsFrameIterator::GetFirstChildInner]

Updated

6 years ago
Crash Signature: [@ nsFrameIterator::GetFirstChildInner] → [@ nsFrameIterator::GetFirstChildInner(nsIFrame*)]
You need to log in before you can comment on or make changes to this bug.