157915 - Crash loading realgm site [@ nsBlockFrame::PullFrameFrom] [@ IsPercentageAwareChild]

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[greer]

The Trunk, M11A and M1.0 Talkback data all show crashes at the
"nsBlockFrame::PullFrameFrom" signature. I have been able to reporduce this one
twice withthe 20020716 Windows build. I alternately get the signature,
"IsPercentageAwareChild".

Possibly related to 145171, cc'ing waterson. (see also WFM bug 120954).

Steps to reproduce:
1. Go to www.realgm.com/src_wiretap.php
2. If you don't crash, try reloading a few times.

-> kmcclusky for reassignment.

Incident 8406999
----------------
Product ID  MozillaTrunk    
Build ID  2002071608    
Operating System  Windows NT 5.0 build 2195    

Stack Trace  
nsBlockFrame::PullFrameFrom
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2744]
nsBlockFrame::PullFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2722]
nsBlockFrame::DoReflowInlineFrames
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3663]
nsBlockFrame::DoReflowInlineFramesAuto
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3523]
nsBlockFrame::ReflowInlineFrames
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3468]
nsBlockFrame::ReflowLine
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2617]
nsBlockFrame::ReflowDirtyLines
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952]
nsBlockReflowContext::DoReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
570]
nsBlockReflowContext::ReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
348]
nsBlockFrame::ReflowBlockFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3229]
nsBlockFrame::ReflowLine
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2483]
nsBlockFrame::ReflowDirtyLines
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableCellFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableCellFrame.cpp, line 946]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableRowFrame::ReflowChildren
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1043]
nsTableRowFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1461]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableRowGroupFrame::ReflowChildren
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 447]
nsTableRowGroupFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1217]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableFrame::ReflowChildren
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 3313]
nsTableFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 2007]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableOuterFrame::OuterReflowChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1027]
nsTableOuterFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1612]
nsBlockReflowContext::DoReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
556]
nsBlockReflowContext::ReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
348]
nsBlockFrame::ReflowBlockFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3229]
nsBlockFrame::ReflowLine
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2483]
nsBlockFrame::ReflowDirtyLines
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableCellFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableCellFrame.cpp, line 946]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableRowFrame::IR_TargetIsChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1300]
nsTableRowFrame::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1191]
nsTableRowFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1453]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableRowGroupFrame::IR_TargetIsChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1630]
nsTableRowGroupFrame::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1298]
nsTableRowGroupFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1207]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableFrame::IR_TargetIsChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 3047]
nsTableFrame::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 2772]
nsTableFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 2024]
nsContainerFrame::ReflowChild
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 830]
nsTableOuterFrame::OuterReflowChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1027]
nsTableOuterFrame::IR_InnerTableReflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1341]
nsTableOuterFrame::IR_TargetIsInnerTableFrame
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1127]
nsTableOuterFrame::IR_TargetIsChild
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1117]
nsTableOuterFrame::IncrementalReflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1079]
nsTableOuterFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1581]
nsBlockReflowContext::DoReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
570]
nsBlockReflowContext::ReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
348]
nsBlockFrame::ReflowBlockFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3229]
nsBlockFrame::ReflowLine
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2483]
nsBlockFrame::ReflowDirtyLines
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2261]
nsBlockFrame::Reflow
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 952]
nsBlockReflowContext::DoReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
570]
nsBlockReflowContext::ReflowBlock
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line
348]
nsBlockFrame::ReflowBlockFrame
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3229]

Comment 1

[greer]

Attachment: Alternate stack

Alternate stack terminating at IsPercentageAwareChild.

Comment 2

[Andrew Schultz]

worksforme with linux build 20020721.  Does this show up on anything but Windows
(OS=All)?

Comment 3

[Andrew Schultz]

bug 152602 and bug 142955 have the same stacks

Comment 4

[Jan Carpenter]

I did a search of the Talkback database, and there are no Linux crashes with the
nsBlockFrame::PullFrameFrom stacktrace since build 2002062408.

The most recent windows crash was from build 2002072104.  

Neither of these stacks are topcrashes on our reports today.

Comment 5

[Kevin McCluskey (gone)]

->karnaze

Comment 6

[greer]

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

Comment 7

[greer]

Chris K. - I just crashed this one at: www.realgm.com/src_wiretap.php 
using build 2002080807 on my machine at home.  The URL (http://dhnet.be/) listed
in bug 152602 has not crashed for me, but that may be due to a change in the
site's content since that bug was logged in June. The realgm site content
changes, but it continues to use a variety of popups which may be related to the
crash. 

Comment 8

[leon.zhang]

very suprised.
I test the testcase using ns7.0Release1 and  mozilla 1.0, and no crash appear.
?

Comment 9

[greer]

Leon, I also tried it immediately following the first crash and was unable to
reporduce it the second time. Since the page serves up a variety of popups is it
possible that the crash could be triggered by a reflow on one of the popups and
not the site itself?

Comment 10

[greer]

Recreated this stack using steps from the crash in bug 167824 (using Win2k and
build from 20020909):

1. Start Mozilla
2. Go to http://espn.go.com/magazine/flemfile_20020910.html
3. File -> Print.
4. Click OK on the print dialog.

Chris K. / moied can you reproduce?

Comment 11

[Moied]

Greer, I can able to reproduce a crash using the steps on comments #10  with 
build 20020910 and 20020906  

Comment 12

[greer]

Moied, I just crashed with the steps in #10 using the 20020916 build on Win2000.
did you reproduce it with a debug build?

Comment 13

[Moied]

I tried on trunk build 20020917 and crash in Comment #11 was from nightly builds.

Comment 14

[karnaze (gone)]

Using comment #10 I can get a crash on my 9/10/2 debug build. I tried it on my
9/16/2 branch build and it didn't crash.

Comment 15

[karnaze (gone)]

Attachment: patch to fix the crash and various assertions

With the patch, the url prints poorly, but I think it may be covered in other
bugs (and may be related to fact that a block inside a table will not split).
If it isn't a dup, let's open a new bug instead of reopening this one after I
check in the patch.

Comment 16

[karnaze (gone)]

Regarding comment #14, this doesn't crash on the branch, because the branch
doesn't have the code to split floaters and the problem is related to that.

Comment 17

[Alexandru Savulov]

Comment on attachment 99906 [details] [diff] [review]
patch to fix the crash and various assertions

r= alexsavulov

Comment 18

[kinmoz]

Comment on attachment 99906 [details] [diff] [review]
patch to fix the crash and various assertions

Karnaze and I already talked about most of this over the phone, I just wanted
to get my review notes in the bug. I believe he will be posting a new patch?


==== No need to get |shell| since |presShell| should be available from code
above.


@@ -5197,6 +5196,21 @@
       nsFrame::ListTag(stdout, aDeletedFrame);
       printf(" prevSibling=%p nextInFlow=%p\n", prevSibling, nextInFlow);
 #endif
+      // If aDeletedFrame is a placeholder, remove it from the placeholder map
+      nsCOMPtr<nsIAtom> fType;
+      aDeletedFrame->GetFrameType(getter_AddRefs(fType));
+      if (nsLayoutAtoms::placeholderFrame == fType) {
+	 nsCOMPtr<nsIPresShell> shell;
+	 aPresContext->GetShell(getter_AddRefs(shell));
+	 if (shell) {


==== Why is this needed? Does the mechanism in place in nsCSSFrameConstructor
not handle this already? I'm just asking cause it seems that's the only code
that ever calls Register/UnregisterPlaceholder.


+	    
frameManager->UnregisterPlaceholderFrame((nsPlaceholderFrame*)aDeletedFrame);


==== Is there any way to accomplish this splitting without the inline knowing
about block stuff?


+    nsCOMPtr<nsIAtom> frameType;
+    aFrame->GetFrameType(getter_AddRefs(frameType));
+    if (nsLayoutAtoms::placeholderFrame == frameType) {
+      nsBlockReflowState* blockRS = lineLayout->mBlockRS;
+      blockRS->mBlock->SplitPlaceholder(*blockRS, *aFrame);


==== This is for making debugging easier right? Perhaps you should add a
comment so that no one rips it out again since it doesn't really do anything.


+nsPlaceholderFrame::nsPlaceholderFrame()
+{
+}
+
+nsPlaceholderFrame::~nsPlaceholderFrame()
+{
+}
+


==== This needs to be |virtual|


+  ~nsPlaceholderFrame();

Comment 19

[karnaze (gone)]

Attachment: revised patch with kin's suggestions

Unregistering the placeholder is probably overkill, since when printing is
done, the hash table is probably going away. 

>==== Is there any way to accomplish this splitting without the inline knowing
>about block stuff?

As we discussed there is no easy way since the containing block and it reflow
state need to do the splitting.

Comment 20

[kinmoz]

Comment on attachment 100455 [details] [diff] [review]
revised patch with kin's suggestions

sr=[e-mail]

==== Just put in a return between the nsPlaceholderFrame constructor and
destructor methods to match the spacing used between methods in that file.

Comment 21

[karnaze (gone)]

Attachment: revised patch with whitespace added

Comment 22

[karnaze (gone)]

The patch is in the trunk.

moied: amar: 

Could one of you please save http://espn.go.com/magazine/flemfile_20020910.html
locally (images need to be local also), so that I can add it to the regression
tests. It would probably be too time consuming to develop a reduced test case.
No need to attach it to this bug, just email it to me.

Comment 23

[Matthias Versen [:Matti]]

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

Comment 24

[greer]

Reopening this one. The fix went in on 9/24 (comment #22) but Trunk data shows
13 crashes since 10/4.

Comment 25

[greer]

Attachment: Current Trunk stack with crashing build range listed.

Here's the current stack and the builds in which this one is crashing.

Comment 26

[karnaze (gone)]

The new stack is not the same (the last 6 or so calls are though) as the ones
for which the bug was fixed. Bug 163614 has a similar stack and was checked in
on 10/8/2. This bug has urls and was fixed against them. If there are crashes
after the 10/9/2 build with this new stack then let's reopen a new bug.

Comment 27

[Olivier Cahagne]

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