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

VERIFIED FIXED in mozilla0.9.5

Status

()

Core
Printing: Output
--
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: hirata masakazu, Assigned: karnaze (gone))

Tracking

({crash, topcrash})

Trunk
mozilla0.9.5
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [AS=in work],PDT, crash signature, URL)

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 35826 [details]
stack trace of the crash resembling bug 80924

Updated

17 years ago
Keywords: crash

Comment 2

17 years ago
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.
(Reporter)

Comment 3

17 years ago
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.

Updated

17 years ago
Target Milestone: --- → mozilla0.9.3
(Reporter)

Comment 4

17 years ago
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.
(Reporter)

Comment 5

17 years ago
Created attachment 37331 [details]
source of the original URL that crashes on print

Updated

17 years ago
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
(Assignee)

Comment 7

17 years ago
This does not crash on Win32 and doesn't appear to be a table paganation issue. 
Reassigning to dcone.
Assignee: karnaze → dcone

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Keywords: nsenterprise

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
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. 

Comment 10

17 years ago
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
(Assignee)

Comment 11

17 years ago
Reassigning to alexsavulov for analysis/triage.
Assignee: karnaze → alexsavulov

Comment 12

17 years ago
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

Comment 13

17 years ago
no time for any repairs, moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 14

17 years ago
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

17 years ago
need reduced test case

Comment 16

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

Comment 17

17 years ago
pushing to 0.9.5
Keywords: nsBranch → nsbranch
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+

Comment 19

17 years ago
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

17 years ago
Jay - What's this look like in the crash report?
Summary: Crash printing this and similar pages. → Crash printing this and similar pages

Comment 21

17 years ago
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

17 years ago
removed keyword nsbranch since it now has nsbranch+, per pdt mtg.
Keywords: nsbranch

Comment 23

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

Comment 24

17 years ago
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

17 years ago
status: working on it
Whiteboard: [AS=in work]

Comment 26

17 years ago
Created attachment 49815 [details]
slightly reduced testcase/ search for NOCRASH to see how not to crash

Comment 27

17 years ago
reassigning to chris karnaze
Assignee: alexsavulov → karnaze
Status: ASSIGNED → NEW
(Assignee)

Comment 28

17 years ago
Created attachment 49961 [details]
more reduced test case that doesn't require japanese char set
(Assignee)

Comment 29

17 years ago
Created attachment 50291 [details] [diff] [review]
patch to fix the crash and defeat the bad effects form data hack resize reflow
(Assignee)

Comment 30

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

Updated

17 years ago
Keywords: patch

Updated

17 years ago
Whiteboard: [AS=in work] → [AS=in work],PDT

Comment 31

17 years ago
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 32

17 years ago
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+

Comment 33

17 years ago
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.






Updated

17 years ago
Attachment #50291 - Flags: superreview+

Comment 34

17 years ago
sr=kin@netscape.com


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

Comment 35

17 years ago
Created attachment 50493 [details] [diff] [review]
revised patch based on reviewer comments.
(Assignee)

Updated

17 years ago
Attachment #50493 - Flags: superreview+
Attachment #50493 - Flags: review+
(Assignee)

Comment 36

17 years ago
The patch has been checked into the trunk and branch.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 37

17 years ago
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]

Comment 38

17 years ago
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
(Assignee)

Comment 39

17 years ago
Reopening, the patch has regressed frameset printing. 
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 40

17 years ago
False alarm. rods has some recent changes that may be incompatible with this 
patch when printing iframes. He is investigating.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 41

17 years ago
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.