140948 - crash when attempting to print/print-preview [@ nsSplittableFrame::Destroy ]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[edward l kaeufer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1)
Gecko/20020417



Reproducible: Always
Steps to Reproduce:
1. to go
http://realtimefilings.nasdaq.com/edgar_conv_html%5C2002%5C04%5C29%5C0000891618-02-002007.html
2. File->Page Setup->disable shrink to page width and set scale to 67%
3. ctrl-P

Actual Results:  crash with error dialog

Expected Results:  printout

Comment 1

[sujay]

confirming....

stack trace = 

FloaterCacheList::~nsFloaterCacheList [nsLineBox.cpp, line 1025] 
nsLineBox::Destroy [nsLineBox.cpp, line 118] 
nsLineBox::DeleteLineList [nsLineBox.cpp, line 322] 
DestroyOverflowLines [nsBlockFrame.cpp, line 4420] 
FrameManager::SetFrameProperty [nsFrameManager.cpp, line 2401] 
nsBlockFrame::SetOverflowLines [nsBlockFrame.cpp, line 4450] 
nsBlockFrame::PushLines [nsBlockFrame.cpp, line 4267] 
nsBlockFrame::PlaceLine [nsBlockFrame.cpp, line 4021] 
nsBlockFrame::DoReflowInlineFrames [nsBlockFrame.cpp, line 3531] 
nsBlockFrame::DoReflowInlineFramesAuto [nsBlockFrame.cpp, line 3381] 
nsBlockFrame::ReflowInlineFrames [nsBlockFrame.cpp, line 3326] 
nsBlockFrame::ReflowLine [nsBlockFrame.cpp, line 2445] 
nsBlockFrame::ReflowDirtyLines [nsBlockFrame.cpp, line 2128] 
nsBlockFrame::Reflow [nsBlockFrame.cpp, line 864] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsTableCellFrame::Reflow [nsTableCellFrame.cpp, line 959] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsTableRowFrame::ReflowChildren [nsTableRowFrame.cpp, line 1040] 
nsTableRowFrame::Reflow [nsTableRowFrame.cpp, line 1461] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsTableRowGroupFrame::ReflowChildren [nsTableRowGroupFrame.cpp, line 449] 
nsTableRowGroupFrame::Reflow [nsTableRowGroupFrame.cpp, line 1213] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsTableFrame::ReflowChildren [nsTableFrame.cpp, line 3460] 
nsTableFrame::ReflowTable [nsTableFrame.cpp, line 2305] 
nsTableFrame::Reflow [nsTableFrame.cpp, line 2162] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsTableOuterFrame::OuterReflowChild [nsTableOuterFrame.cpp, line 1028] 
nsTableOuterFrame::Reflow [nsTableOuterFrame.cpp, line 1616] 
nsBlockReflowContext::DoReflowBlock [nsBlockReflowContext.cpp, line 581] 
nsBlockReflowContext::ReflowBlock [nsBlockReflowContext.cpp, line 359] 
nsBlockFrame::ReflowBlockFrame [nsBlockFrame.cpp, line 3082] 
nsBlockFrame::ReflowLine [nsBlockFrame.cpp, line 2350] 
nsBlockFrame::ReflowDirtyLines [nsBlockFrame.cpp, line 2128] 
nsBlockFrame::Reflow [nsBlockFrame.cpp, line 864] 
nsBlockReflowContext::DoReflowBlock [nsBlockReflowContext.cpp, line 581] 
nsBlockReflowContext::ReflowBlock [nsBlockReflowContext.cpp, line 359] 
nsBlockFrame::ReflowBlockFrame [nsBlockFrame.cpp, line 3082] 
nsBlockFrame::ReflowLine [nsBlockFrame.cpp, line 2350] 
nsBlockFrame::ReflowDirtyLines [nsBlockFrame.cpp, line 2128] 
nsBlockFrame::Reflow [nsBlockFrame.cpp, line 864] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsPageContentFrame::Reflow [nsPageContentFrame.cpp, line 98] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsPageFrame::Reflow [nsPageFrame.cpp, line 228] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
nsSimplePageSequenceFrame::Reflow [nsSimplePageSequence.cpp, line 447] 
nsContainerFrame::ReflowChild [nsContainerFrame.cpp, line 807] 
ViewportFrame::Reflow [nsViewportFrame.cpp, line 588] 
PresShell::InitialReflow [nsPresShell.cpp, line 2653] 
DocumentViewerImpl::ReflowPrintObject [nsDocumentViewer.cpp, line 3893] 
DocumentViewerImpl::ReflowDocList [nsDocumentViewer.cpp, line 3648] 
DocumentViewerImpl::SetupToPrintContent [nsDocumentViewer.cpp, line 4432] 
DocumentViewerImpl::DocumentReadyForPrinting [nsDocumentViewer.cpp, line 5252] 
DocumentViewerImpl::Print [nsDocumentViewer.cpp, line 7083] 
XPTC_InvokeByIndex [xptcinvoke.cpp, line 106] 
XPCWrappedNative::CallMethod [xpcwrappednative.cpp, line 1995] 
XPC_WN_CallMethod [xpcwrappednativejsops.cpp, line 1267] 
js_Invoke [jsinterp.c, line 790] 
js_Interpret [jsinterp.c, line 2744] 
js_Invoke [jsinterp.c, line 806] 
js_InternalInvoke [jsinterp.c, line 881] 
JS_CallFunctionValue [jsapi.c, line 3414] 
nsJSContext::CallEventHandler [nsJSEnvironment.cpp, line 1019] 

Comment 2

[rods (gone)]

over to chris, I have seen something similar

Comment 3

[karnaze (gone)]

we need a reduced test case.

Comment 4

[Stuart Brown]

Similar problem Win98SE; unsure if dupe of this or 137902 or new bug.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
TB15027476Z

Reproducible always:
1. http://www.pcmag.com/article2/0,4149,715464,00.asp
2. File > Print Preview, click Landscape

Result:
Crash (if scale "shrink to fit" or 90% or greater, no crash at 80% or less)

NB don't need to "Print". FWIW page break between pages 1 and 2 is odd at 60-80%
landscape, as it is in previews of http://news.bbc.co.uk/default.stm (high
visibility site; also contains iframe; does not crash).

Comment 5

[Stuart Brown]

My problem is definitely due to the iframe, so I have created bug 185357 (the
reporter's URL has no iframe).

Comment 6

[Stuart Brown]

Attachment: test case

To make up for the above spam, here is a test case. The problem seems to be in
the style="page-break-before:always"; if those are removed from the reporter's
URL it works for me.

To reproduce:
1. Print preview the test case (with page setup at the defaults of shrink to
fit and portrait).
2. Close print preview (or change page layout).
3. Crash.

Notes on the test case:
* Removing <br>s from the test case means you need to change the scale or page
layout to get the crash.
* The <h1>'s may be replacable by <div>'s (I replaced a div with h1 during
reduction of the test case).

TB15380794W

Comment 7

[Olivier Cahagne]

stack from linux debug build 20021226 loading testcase from comment 6.

#0  0xdddddddd in ?? ()
#1  0x41b0a99a in nsSplittableFrame::Destroy (this=0x8a468e0, 
    aPresContext=0x8c32098) at nsSplittableFrame.cpp:68
#2  0x41aa8346 in nsContainerFrame::Destroy (this=0x8a468e0, 
    aPresContext=0x8c32098) at nsContainerFrame.cpp:145
#3  0x41a932db in nsBlockFrame::Destroy (this=0x8a468e0, 
    aPresContext=0x8c32098) at nsBlockFrame.cpp:424

Comment 8

[Olivier Cahagne]

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

Comment 9

[karnaze (gone)]

mass reassign to default owner

Comment 10

[Bernd]

print bug

Comment 11

[Mats Palmgren (inactive)]

(URL is 404 so I'm changing it to the URL from dupe bug 185799)

This is really a Style System / Layout bug...

The problem here is that nsCSSFrameConstructor::CreateContinuingFrame() does
not handle the next-in-flow chain correctly leading to a frame tree like this:

  TableRow(tr)(0)@0x86e8f40 next=0x86f245c next-in-flow=0x86f245c ...<
    TableCell(td)(0)@0x86e90c4 next-in-flow=0x86f24b0 ...<
      Block(td)(0)@0x86e913c next-in-flow=0x86f2510 ...<

[ ... stuff deleted ...]

  TableRow(tr)(0)@0x86f245c next=0x86f2190 prev-in-flow=0x86e8f40 ...<
    TableCell(td)(0)@0x86f24b0 prev-in-flow=0x86e90c4 ...<
      Block(td)(0)@0x86f2510 prev-in-flow=0x86e913c ...<
      >
    >
  >
  TableRow(tr)(0)@0x86f2190 prev-in-flow=0x86e8f40 ...<
    TableCell(td)(0)@0x86f21e4 prev-in-flow=0x86e90c4 ...<
      Block(td)(0)@0x86f2244 prev-in-flow=0x86e913c ...<

The crash occurs when the last row is Destroy()'ed because its prev-in-flow
has already been deleted.

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (distilled from URL)

Crash occurs on "Close" in Print Preview.  (with default "Page Setup" settings)

Comment 13

[Mats Palmgren (inactive)]

Attachment: Trace output from "Testcase #2"

This file is quite big so I have marked the interesting lines with "mats"

Comment 14

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 15

[Mats Palmgren (inactive)]

Comment on attachment 135694 [details] [diff] [review]
Patch rev. 1

BTW, this does not help bug 185357 which a similar but different problem...

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Who's calling CreateContinuingFrame for a frame that already has a continuation?
 Should it support that, or is it better to fix the caller?

Comment 17

[Mats Palmgren (inactive)]

1. nsTableRowGroupFrame
2. In "Testcase #2" where we have two 'page-break-before:always'
   in the same table cell -- how can we avoid it?

Also, I think we have to trigger an 'Overflow-list' for the crash to occur.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> 2. In "Testcase #2" where we have two 'page-break-before:always'
>    in the same table cell -- how can we avoid it?

But why wouldn't we do things in order, so that the second call would be
creating a continuation for the continuation rather than for the first frame? 
(This patch makes it look like things happen in reverse order.)

Comment 19

[Mats Palmgren (inactive)]

Attachment: Call stack 1

Here is more precise answer to 1.
nsTableRowGroupFrame::SplitRowGroup, line 1113

We do hit the assertion on line 1112 with "Testcase #2".

To continue my speculation on 2. - I think decisions to split the row-group
can happen in different reflow passes and then you could potentially have a
next-in-flow already from a previous reflow. (just guessing though - you have
to ask someone who actually understands table reflow ;-)

Comment 20

[Mats Palmgren (inactive)]

Attachment: Trace output to go with "Call stack 1"

Frame dumps from nsTableRowGroupFrame::SplitRowGroup and also (at the end) in
nsCSSFrameConstructor::CreateContinuingFrame when there is a NextInFlow.

Comment 21

[Mats Palmgren (inactive)]

> To continue my speculation on 2.

That wasn't very clear, what I mean is, if you have: <tr><td>X Y Z...
we could find a reason to split before Z on the first pass and then find
another reason to split before Y on the second pass.

Comment 22

[Andrew Schultz]

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

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 135694 [details] [diff] [review]
Patch rev. 1

Sorry for missing this for so long.  Please bug me when I do that in the
future...

Comment 24

[chris hofmann]

Comment on attachment 135694 [details] [diff] [review]
Patch rev. 1

a=chofmann for 1.7

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Patch checked in to trunk, 2004-04-01 16:10 -0800.