Closed Bug 82401 Opened 24 years ago Closed 23 years ago

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

Categories

(Core :: Printing: Output, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: tarahim, Assigned: karnaze)

References

()

Details

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

Crash Data

Attachments

(6 files)

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.
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 www.asahi.com, 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 trace.
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
Status: NEW → ASSIGNED
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 crash.
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
Status: ASSIGNED → NEW
In the attachment, I plan to change (even though they are the same value) pageSize.height = NS_MAXSIZE; to pageSize.height = NS_UNCONSTRAINEDSIZE;
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 - 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.
Attachment #50291 - Flags: superreview+
sr=kin@netscape.com 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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Adding topcrash and N610 [@ nsFrameList::DestroyFrames] to summary for future reference.
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 crash. will re-verify in trunk when I get chance.
Status: RESOLVED → VERIFIED
Reopening, the patch has regressed frameset printing.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
False alarm. rods has some recent changes that may be incompatible with this patch when printing iframes. He is investigating.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
whew marking verified again.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsFrameList::DestroyFrames]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: