82401 - Crash printing this and similar pages - N610 [@ nsFrameList::DestroyFrames]

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[hirata masakazu]

2001052308 and 0518 trunk build for Mac
Goto URL or other pages in www.asahi.com
Print
Result crash right after print job is finished.

Comment 1

[hirata masakazu]

Attachment: stack trace of the crash resembling bug 80924

Comment 2

[dcone (gone)]

I dont know what pages are simular to this.. can you be more specific about what 
that simularity is.  That may help narrow down what the problem is.

Comment 3

[hirata masakazu]

I would like to if I could. Since this is a NEWS site, I can not guarantee the
URL given will not change its content. I have not come up yet with other sites
that crashes in a similar stack trace. I will report when I find one.

Comment 4

[hirata masakazu]

I have been trying to have a minimized test case for this. When I delete some
content from one of the table cell, it prints all right. But it is not dependent
of some specific cell. It may be just the complexity of the table that is
crashing in printing. I will attach a so-far minimal source from the original
URL that crashes on print, since the URL is not available on the server. It is
still crashing in similar pages from www.asahi.com, though.

Comment 5

[hirata masakazu]

Attachment: source of the original URL that crashes on print

Comment 6

[Kevin McCluskey (gone)]

Reassigning to karnaze, hirata masakazu reports that the crashing is related to
content in table cells.

Comment 7

[karnaze (gone)]

This does not crash on Win32 and doesn't appear to be a table paganation issue. 
Reassigning to dcone.

Comment 8

[Kevin McCluskey (gone)]

It crashes on WINNT with a 2001062504 build. Changing platform to ALL

Comment 9

[Kevin McCluskey (gone)]

It does not crash using a debug build on WINNT from today, the 2001062504 build
which crashed was a release build. 

Comment 10

[dcone (gone)]

This does with the current build and I can get it to crash with the debug but 
the stack trace is messed up.  Based on the stacktrace that was captured, it 
seems that an object is being referenced that has been deleted at 
nsHTMLTableElement::Release().  I am giving this to karnaze bases on that stack 
trace.

Comment 11

[karnaze (gone)]

Reassigning to alexsavulov for analysis/triage.

Comment 12

[Alexandru Savulov]

confirming unhandled exception in the branch 0.9.2 and trunk
(seems there is a wild nsTextFrame)

here is the stack:

nsTableRowGroupFrame::Reflow(nsTableRowGroupFrame * const 0x049df2b4, 
nsIPresContext * 0x049cb7d0, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 1065
nsContainerFrame::ReflowChild(nsIFrame * 0x049df2b4, nsIPresContext * 
nsTableFrame::ReflowChildren(nsTableFrame * const 0x049df218, nsIPresContext * 
nsTableFrame::Reflow(nsTableFrame * const 0x049df218, nsIPresContext * 
nsContainerFrame::ReflowChild(nsIFrame * 0x049df218, nsIPresContext * 
nsTableOuterFrame::OuterReflowChild(nsTableOuterFrame * const 0x049ddd28, 
nsIPresContext * 0x049cb7d0, nsIFrame * 0x049df218, const nsHTMLReflowState & 
nsTableOuterFrame::Reflow(nsTableOuterFrame * const 0x049ddd28, nsIPresContext * 
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x049ddd28, const nsRect & {x=0 
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x04a183e8, int 
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2026 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x049ccb2c, nsIPresContext * 
nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason 
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x049ccb2c, const nsRect & {x=0 y=0 
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x04a184b0, int 
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2026 + 27 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x049cc7b0, nsIPresContext * 
nsContainerFrame::ReflowChild(nsIFrame * 0x049cc7b0, nsIPresContext * 
nsPageFrame::Reflow(nsPageFrame * const 0x049cc304, nsIPresContext * 0x049cb7d0, 
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) 
nsContainerFrame::ReflowChild(nsIFrame * 0x049cc304, nsIPresContext * 
nsSimplePageSequenceFrame::Reflow(nsSimplePageSequenceFrame * const 0x049cc1ac, 
nsIPresContext * 0x049cb7d0, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, unsigned int & 0) line 344
nsContainerFrame::ReflowChild(nsIFrame * 0x049cc1ac, nsIPresContext * 
PresShell::StyleChangeReflow(PresShell * const 0x0494a768) line 3268
DocumentViewerImpl::ReflowPrintObject(PrintObject * 0x044b7d08) line 2867
DocumentViewerImpl::ReflowDocList(PrintObject * 0x044b7d08) line 2659 + 12 bytes
DocumentViewerImpl::SetupToPrintContent(nsIWebShell * 0x040216c8, 
nsIDeviceContext * 0x04906c28, nsIDOMWindowInternal * 0x00000000) line 3161 + 24 
DocumentViewerImpl::DocumentReadyForPrinting() line 3928 + 42 bytes
DocumentViewerImpl::Print(DocumentViewerImpl * const 0x0493bea0, int 0, _iobuf * 
GlobalWindowImpl::Print(GlobalWindowImpl * const 0x0408dc24) line 1873 + 29 
XPTC_InvokeByIndex(nsISupports * 0x0408dc24, unsigned int 69, unsigned int 0, 
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
XPC_WN_CallMethod(JSContext * 0x03e5d7e8, JSObject * 0x03efe3a0, unsigned int 0, 
js_Invoke(JSContext * 0x03e5d7e8, unsigned int 0, unsigned int 0) line 807 + 23 
js_Interpret(JSContext * 0x03e5d7e8, long * 0x0012e460) line 2702 + 15 bytes
js_Invoke(JSContext * 0x03e5d7e8, unsigned int 1, unsigned int 2) line 824 + 13 
js_InternalInvoke(JSContext * 0x03e5d7e8, JSObject * 0x04091df0, long 71518784, 
JS_CallFunctionValue(JSContext * 0x03e5d7e8, JSObject * 0x04091df0, long 
nsJSContext::CallEventHandler(nsJSContext * const 0x034f8018, void * 0x04091df0, 
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x041aa598, nsIDOMEvent 
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x041aa648, 
nsIDOMEvent * 0x04825654, nsIDOMEventTarget * 0x041bbc98, unsigned int 8, 
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x041aa520, 
nsIPresContext * 0x033fb180, nsEvent * 0x0012f140, nsIDOMEvent * * 0x0012f004, 
nsIDOMEventTarget * 0x041bbc98, unsigned int 7, nsEventStatus * 0x0012f188) line 
nsXULElement::HandleDOMEvent(nsXULElement * const 0x041bbc90, nsIPresContext * 
nsEventStatus * 0x0012f188) line 3635
PresShell::HandleDOMEventWithTarget(PresShell * const 0x033fb808, nsIContent * 
nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x033fb180, nsGUIEvent * 
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x041ba4d0, 
nsIPresContext * 0x033fb180, nsGUIEvent * 0x0012f33c, nsEventStatus * 
PresShell::HandleEventInternal(nsEvent * 0x0012f33c, nsIView * 0x00000000, 
PresShell::HandleEventWithTarget(PresShell * const 0x033fb808, nsEvent * 
nsEventStatus * 0x0012f648) line 5537 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
nsEventStatus * 0x0012f648) line 2464 + 61 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03da8e88, 
nsIPresContext * 0x033fb180, nsEvent * 0x0012f754, nsIFrame * 0x041ba4d0, 
nsEventStatus * 0x0012f648, nsIView * 0x0370c668) line 1549 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f754, nsIView * 0x0370c668, 
PresShell::HandleEvent(PresShell * const 0x033fb80c, nsIView * 0x0370c668, 
nsGUIEvent * 0x0012f754, nsEventStatus * 0x0012f648, int 1, int & 1) line 5491 + 
nsView::HandleEvent(nsView * const 0x0370c668, nsGUIEvent * 0x0012f754, unsigned 
nsViewManager::DispatchEvent(nsViewManager * const 0x0370c418, nsGUIEvent * 
HandleEvent(nsGUIEvent * 0x0012f754) line 68
nsWindow::DispatchEvent(nsWindow * const 0x033fde64, nsGUIEvent * 0x0012f754, 
nsEventStatus & nsEventStatus_eIgnore) line 720 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f754) line 741
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=??? 
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000 {x=??? 
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 2949890, long * 
nsWindow::WindowProc(HWND__ * 0x0002089e, unsigned int 514, unsigned int 0, long 

Comment 13

[Alexandru Savulov]

no time for any repairs, moving to 0.9.4

Comment 14

[Alexandru Savulov]

ok, we have more bugs on this japaneese site:

1. is crashing at:

nsFrameList::DestroyFrames(nsIPresContext * 0x03b78b08) line 115
....
(see first attachment)

2. is crashing at:

PresShell::ResizeReflow(PresShell * const 0x04aa4380, int 11729, int 15338) line 
2759 + 14 bytes
DocumentViewerImpl::ReflowPrintObject(PrintObject * 0x04a018e0) line 2929
....

3 is crashing at:

nsTableRowGroupFrame::Reflow(nsTableRowGroupFrame * const 0x049df2b4, 
nsIPresContext * 0x049cb7d0, nsHTMLReflowMetrics & {...}, const
....
(see my stack)

For 2. and 3. I have to open different bugs.
 

Comment 15

[Alexandru Savulov]

need reduced test case

Comment 16

[Jussi-Pekka Mantere]

About to blow away nsenterprise keyword. Montse, do you care for this for 
international support?

Comment 17

[Alexandru Savulov]

pushing to 0.9.5

Comment 18

[Kevin McCluskey (gone)]

Marking nsbranch+. Crash appears to be related to particular table configuration
not specific to language.

Comment 19

[kinmoz]

After a quick look in the debugger, this looks similar to bug 92215, but 
I'm not sure floaters are involved in this specific case ... but, with the 
sample page nsTableRowGroupFrame::SplitRowGroup() is definitely getting 
triggered, and various Table continuing frames are being deleted just before we 
crash.

Comment 20

[Jaime Rodriguez, Jr.]

Jay - What's this look like in the crash report?

Comment 21

[Jay Patel [:jay]]

This crash isn't showing up in any recent Talkback topcrash reports.  This is
still a topcrasher for N610, but there are only a few crashes reported for M093
and only 6 crashes on the MozillaTrunk in the last 30 days.  This does look a
lot like bug 92215, as Kin said...

Comment 22

[elaineking]

removed keyword nsbranch since it now has nsbranch+, per pdt mtg.

Comment 23

[Jaime Rodriguez, Jr.]

Pls let the PDT know where there is more progress on this one.

Comment 24

[kinmoz]

FYI, I just attatched a patch to bug 92215, that fixes it and some of it's dups. 

It did not fix the crash that happens with the URL used in this bug, so it seems 
like this is a totally different issue.

Comment 25

[Alexandru Savulov]

status: working on it

Comment 26

[Alexandru Savulov]

Attachment: slightly reduced testcase/ search for NOCRASH to see how not to crash

Comment 27

[Alexandru Savulov]

reassigning to chris karnaze

Comment 28

[karnaze (gone)]

Attachment: more reduced test case that doesn't require japanese char set

Comment 29

[karnaze (gone)]

Attachment: patch to fix the crash and defeat the bad effects form data hack resize reflow

Comment 30

[karnaze (gone)]

In the attachment, I plan to change (even though they are the same value)
pageSize.height = NS_MAXSIZE; to
pageSize.height = NS_UNCONSTRAINEDSIZE;

Comment 31

[Marc Attinasi]

Comment on attachment 50291 [details] [diff] [review]
patch to fix the crash and defeat the bad effects form data hack resize reflow

sr=attinasi - Why not just remove the implementation of PullUpChildren too, since it is ot called and you removed the declaration? Also, I'm assuming you will check in the regression test.

Comment 32

[Marc Attinasi]

Comment on attachment 50291 [details] [diff] [review]
patch to fix the crash and defeat the bad effects form data hack resize reflow

Oops - I meant r=attinasi, either ways is fine, actually.

Comment 33

[kinmoz]

karnaze and I spoke by phone, and he said he would be removing
the table pull up code completely, but leaving a comment in the
header files noting it's existence in CVS, just in case someone
had a reason to revisit the issue.

Changes look fine to me. I would probably make a couple of word
adjustments in the following comments to avoid confusing anyone
who might be removing the FORM-DATA-HACK code in the future:



>Index: content/base/src/nsDocumentViewer.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/content/base/src/nsDocumentViewer.cpp,v
>retrieving revision 1.146
>diff -u -r1.146 nsDocumentViewer.cpp
>--- nsDocumentViewer.cpp	2001/09/12 23:31:33	1.146
>+++ nsDocumentViewer.cpp	2001/09/21 18:57:16
>@@ -2866,7 +2866,12 @@
>   }
> 
>   aPO->mPresContext->SetPageDim(&adjRect);
>-  rv = aPO->mPresShell->InitialReflow(width, height);
>+  // XXX FORM-DATA-HACK - replace this line with the commented one below it
when the hack at the end of 
>+  // this method doing the resize reflow is fixed. By doing an intitial reflow
with an unconstrained 


Should probably replace the word "fixed" with "removed".


>Index: layout/html/base/src/nsSimplePageSequence.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/layout/html/base/src/nsSimplePageSequence.cpp,v
>retrieving revision 3.47
>diff -u -r3.47 nsSimplePageSequence.cpp
>--- nsSimplePageSequence.cpp	2001/07/25 07:52:15	3.47
>+++ nsSimplePageSequence.cpp	2001/09/21 18:59:08
>@@ -335,7 +342,13 @@
>                                        availSize, reflowReason);
>       nsReflowStatus  status;
>       kidReflowState.availableWidth  = pageSize.width - margin.left -
margin.right;
>-      kidReflowState.availableHeight = pageSize.height - margin.top -
margin.bottom;
>+      // XXX FORM-DATA-HACK remove these 3 lines with the commented one when a
resize reflow is no 
>+      // longer needed to get form data. See also FORM-DATA-HACK in
nsDocumentViewer::ReflowPrintObject


We should probably say "replace" these 3 lines with the commented one.

Comment 34

[kinmoz]

sr=[e-mail]


Before checkin, lets make sure that we still produce the same output when printing.

Comment 35

[karnaze (gone)]

Attachment: revised patch based on reviewer comments.

Comment 36

[karnaze (gone)]

The patch has been checked into the trunk and branch.

Comment 37

[Jay Patel [:jay]]

Adding topcrash and N610 [@ nsFrameList::DestroyFrames] to summary for future
reference.

Comment 38

[sujay]

verified in 9/25 build. it does not crash anymore.
It was a small easter egg hunt looking for a similar page
to the URL above which does not exist anymore. we found
a page that did exhibit the crash on 9/24 build and then we
printed that very same page out using 9/25 build and it did not
crash. 

will re-verify in trunk when I get chance.

Comment 39

[karnaze (gone)]

Reopening, the patch has regressed frameset printing. 

Comment 40

[karnaze (gone)]

False alarm. rods has some recent changes that may be incompatible with this 
patch when printing iframes. He is investigating.

Comment 41

[sujay]

whew

marking verified again.