288790 - [FIX]Crash [@ GetNearestContainingBlock] with this xbl testcase

Status: RESOLVED FIXED

(Core :: XBL, defect, P1)

Description

[Martijn Wargers (dead)]

Related bugs: bug 194952 and bug 287981

The following testcase that I'll attach crashes Mozilla.
Talkback ID: TB4792287X

GetNearestContainingBlock 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp,
line 591]
nsHTMLReflowState::InitAbsoluteConstraints 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp,
line 994]
nsHTMLReflowState::InitConstraints 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp,
line 1926]
nsHTMLReflowState::Init 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp,
line 337]
nsHTMLReflowState::nsHTMLReflowState 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLReflowState.cpp,
line 310]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,
line 531]
nsAbsoluteContainingBlock::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,
line 208]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 1044]
nsBlockReflowContext::ReflowBlock 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockReflowContext.cpp,
line 571]
nsBlockFrame::ReflowBlockFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 3431]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 2582]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 2251]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 875]
nsBlockReflowContext::ReflowBlock 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockReflowContext.cpp,
line 571]
nsBlockFrame::ReflowBlockFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 3431]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 2582]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 2251]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 875]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 954]
CanvasFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsHTMLFrame.cpp,
line 522]
nsFrame::BoxReflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsFrame.cpp,
line 5379]
nsFrame::DoLayout 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsFrame.cpp,
line 5121]
nsIFrame::Layout 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 802]
nsIFrame::Layout 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 802]
nsGfxScrollFrameInner::LayoutBox 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1624]
nsHTMLScrollFrame::DoLayout 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 1041]
nsIFrame::Layout 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 802]
nsXULScrollFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 989]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 954]
ViewportFrame::Reflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/generic/nsViewportFrame.cpp,
line 240]
IncrementalReflow::Dispatch 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 908]
PresShell::ProcessReflowCommands 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6669]
PresShell::WillPaint 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6427]
SHELL32.dll + 0x520c24 (0x778b0c24)

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 2

[Martijn Wargers (dead)]

Well, it doesn't seem to crash online. You have to save it locally and then
click on the button in the testcase.

Comment 3

[Martijn Wargers (dead)]

Attachment: Backtrace from debug build

Comment 4

[Jay Patel [:jay]]

*** This bug has been marked as a duplicate of 194952 ***

Comment 5

[Boris Zbarsky [:bzbarsky]]

I doubt this is a duplicate, especially since this DOES crash on trunk and bug
194952 does NOT.  Please, please look at more than just the top thing on the stack?

Comment 6

[Worcester12345]

WFM on the test case. I am using a branch and the bug says trunk, but I am
pretty sure THIS branch is off THAT trunk, not the more recent (Aug 2005) trunk
since the bug was opened in April.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050818
Firefox/1.0+

Maybe the original reporter can retry with latest branch and trunk builds.

Comment 7

[Martijn Wargers (dead)]

Still crashes for me with the latest nightly trunk build.
Remember that you have to download the testcase and test it locally (don't try
the testcase first, because it messes with the dom).

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

So nsCSSFrameConstructor::ContentRemoved is just confused.  It should just be
using the parent of the primary frame, instead of looking for insertion points,
since that parent _is_ the right parent frame.	The insertion point will just
be equivalent for in-flow content, and for out-of-flows it'll give totally the
wrong parent.

What happened here is that when we set the binding the first time, the parent
frame of the <span> is that for the outer <div>, but the insertion point (the
parent of the placeholder) is the inner div's frame.  Then when we reframe for
the binding URI change we try to remove the abs pos frame from the _inner_
div's absolute list, which of course fails.  Then we have random frames hanging
about that should be dead, apparently with reflow commands targeted at them...
because we try to reflow the abs pos frame in question and die because it no
longer has a placeholder.

The fix is to just not mess with the parent in ContentRemoved.

I do think we should consider this for the 1.8 branch...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 196875 [details] [diff] [review]
Fix

Requesting 1.8b5 approval.  This is reasonably safe, fixes a crash (which could
well be as exploitable as the StirDOM stuff we've been seeing).

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed on branch.

Comment 12

[Jesse Ruderman]

*** Bug 307854 has been marked as a duplicate of this bug. ***

Comment 13

[Jesse Ruderman]

Moving [sg:fix] here from dup.

Comment 14

[Jay Patel [:jay]]

v.fixed on branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5)
Gecko/20050929 Firefox/1.4, testcase does not crash (from attachment or locally).

Comment 15

[Bob Clary [:bc] (inactive)]

crash test landed
http://hg.mozilla.org/mozilla-central/rev/2a3373652983