Closed Bug 82401 Opened 21 years ago Closed 21 years ago

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


(Core :: Printing: Output, defect)

Not set





(Reporter: tarahim, Assigned: karnaze)




(Keywords: crash, topcrash, Whiteboard: [AS=in work],PDT)

Crash Data


(6 files)

2001052308 and 0518 trunk build for Mac
Goto URL or other pages in
Result crash right after print job is finished.
Keywords: crash
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.
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.
Target Milestone: --- → mozilla0.9.3
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, though.
Target Milestone: mozilla0.9.3 → mozilla0.9.2
Reassigning to karnaze, hirata masakazu reports that the crashing is related to
content in table cells.
Assignee: dcone → karnaze
This does not crash on Win32 and doesn't appear to be a table paganation issue. 
Reassigning to dcone.
Assignee: karnaze → dcone
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Keywords: nsenterprise
Keywords: nsBranch
OS: Mac System 8.5 → All
Hardware: Macintosh → All
It crashes on WINNT with a 2001062504 build. Changing platform to ALL
It does not crash using a debug build on WINNT from today, the 2001062504 build
which crashed was a release build. 

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 
Assignee: dcone → karnaze
Reassigning to alexsavulov for analysis/triage.
Assignee: karnaze → alexsavulov
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 

no time for any repairs, moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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.

need reduced test case
About to blow away nsenterprise keyword. Montse, do you care for this for 
international support?
pushing to 0.9.5
Keywords: nsBranchnsbranch
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Marking nsbranch+. Crash appears to be related to particular table configuration
not specific to language.
Keywords: nsbranch+
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 
Jay - What's this look like in the crash report?
Summary: Crash printing this and similar pages. → Crash printing this and similar pages
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...
removed keyword nsbranch since it now has nsbranch+, per pdt mtg.
Keywords: nsbranch
Pls let the PDT know where there is more progress on this one.
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.
status: working on it
Whiteboard: [AS=in work]
reassigning to chris karnaze
Assignee: alexsavulov → karnaze
In the attachment, I plan to change (even though they are the same value)
pageSize.height = NS_MAXSIZE; to
Keywords: patch
Whiteboard: [AS=in work] → [AS=in work],PDT
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.
Attachment #50291 - Flags: superreview+
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.
Attachment #50291 - Flags: superreview+ → review+
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 -
>-      kidReflowState.availableHeight = pageSize.height - -
>+      // 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

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

Attachment #50291 - Flags: superreview+

Before checkin, lets make sure that we still produce the same output when printing.
Attachment #50493 - Flags: superreview+
Attachment #50493 - Flags: review+
The patch has been checked into the trunk and branch.
Closed: 21 years ago
Resolution: --- → FIXED
Adding topcrash and N610 [@ nsFrameList::DestroyFrames] to summary for future
Keywords: topcrash
Summary: Crash printing this and similar pages → Crash printing this and similar pages - N610 [@ nsFrameList::DestroyFrames]
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

will re-verify in trunk when I get chance.
Reopening, the patch has regressed frameset printing. 
Resolution: FIXED → ---
False alarm. rods has some recent changes that may be incompatible with this 
patch when printing iframes. He is investigating.
Closed: 21 years ago21 years ago
Resolution: --- → FIXED

marking verified again.
Crash Signature: [@ nsFrameList::DestroyFrames]
You need to log in before you can comment on or make changes to this bug.