Closed Bug 163614 Opened 22 years ago Closed 22 years ago

mozilla crashes when trying to print this page (or print preview)

Categories

(Core :: Printing: Output, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.2alpha

People

(Reporter: fleuenb, Assigned: karnaze)

References

()

Details

(Keywords: crash, hang, regression)

Attachments

(3 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721

mozilla crashes at 0x60740501 when printing or print previewing this page:
unhandled exception in mozilla.exe (GKLAYOUT.DLL) 0xC0000005 Access violation


Reproducible: Always

Steps to Reproduce:
1. go to http://www.eeel.nist.gov/812/effe.htm
2. try to print or print preview
3.

Actual Results:  
mozilla crashes

Expected Results:  
mozilla should have printed the page

unhandled exception in mozilla.exe (GKLAYOUT.DLL) 0xC0000005 Access violation
confirming crash using build 2002081905 on Linux (trunk): TB9601684Q.
Severity: normal → critical
Keywords: crash, stackwanted
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [has TB ID]
Keywords: stackwanted
Whiteboard: [has TB ID]
This is the html source of the page that crashes mozilla when trying to print
or preview the page. When you rename (or  remove) the file 'figs1.jpg' in the
'effes_files' folder the page will be previewed correctly , except the image
you removed ;)
Attachment #96001 - Attachment mime type: application/octet-stream → application/zip
Attachment #96001 - Attachment mime type: application/zip → application/zip (*.zip)
Attachment #96001 - Attachment mime type: application/zip (*.zip) → text/zip
Attachment #96001 - Attachment mime type: text/zip → application/zip
a frame is garabage, stack trace:
nsIFrame::GetStyleData(nsStyleStructID eStyleStruct_Margin, const nsStyleStruct
* & 0x02c9f511) line 578 + 16 bytes
IsPercentageAwareChild(const nsIFrame * 0x03ec0db8) line 1187 + 14 bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, nsIFrame * 0x03ec0db8, unsigned char *
0x001272f4) line 3825 + 9 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, int * 0x00127a34, unsigned char * 0x001277f4,
int 0, int 0) line 3740 + 32 bytes
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...},
nsLineList_iterator {...}, int * 0x00127a34, unsigned char * 0x001277f4, int 0,
int 0) line 3604 + 46 bytes
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x00127a34, int 0, int 0) line 3548 + 36 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x00127a34, int 0) line 2628 + 33 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2272 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x03aa81b4, nsIPresContext *
0x03d485a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 949 + 15 bytes
nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason
eReflowReason_Resize, nsIFrame * 0x03aa81b4, const nsRect & {x=0 y=6088
width=7080 height=1073741824}, int 1, nsCollapsingMargin & {...}, int 0,
nsMargin & {top=0 right=0 bottom=0 left=0}, unsigned int & 0) line 569 + 36 bytes
nsBlockReflowContext::ReflowBlock(nsIFrame * 0x03aa81b4, const nsRect & {x=0
y=6088 width=7080 height=1073741824}, int 1, nsCollapsingMargin & {...}, int 0,
nsMargin & {top=0 right=0 bottom=0 left=0}, unsigned int & 0) line 345 + 50 bytes
Assignee: rods → karnaze
Status: UNCONFIRMED → NEW
Ever confirmed: true
WFM 1.1b Linux i386  print in file

But: first page is colored header only, then a page break, 
and the rest appears correctly. 
So this is a regression.
I get a hang here (print and preview) on Linux trunk builds.  Mozilla 1.0 branch
works ok.  regression on the trunk between 2002052808 and 2002052908.
(bug 145305 ?).

Debug build loops forever printing this assertion:
###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5506
Keywords: hang
this is a regression from bug 145305
Depends on: 145305
Keywords: regression
I am getting the same problem with Mozilla Build 2002052918 french on a
RedHat7.2 machine. I can reproduce with every web page during printing or
previewing.
Blocks: 157675
Attached patch patch to fix the bug (obsolete) — Splinter Review
The patch changes DeleteChildsNextInFlow(nsIPresContext*, nsIFrame* aChild)
which gets called on the parent of aChild to
 
DeleteNextInFlow(nsIPresContext*, nsIFrame* aPrevInFlow, nsIFrame* aNextInFlow)
which gets called on the parent of aNextInFlow

aNextInFlow does not need to be passed in, but it seems cleaner since it is
related to "this" and all of the callers must get it anyway.
Attached patch same patch with a name change (obsolete) — Splinter Review
Changed DeleteNextInFlow() to DeleteNextInFlowChild().
Attachment #101488 - Attachment is obsolete: true
Attachment #101493 - Attachment is obsolete: true
Comment on attachment 101547 [details] [diff] [review]
same patch with aPrevInFlow param removed

The |DeleteNextInFlowChild()| changes look ok to me since you've explained to
me the situation and why it was necessary.

I'm a little on the fence about the |IsChild()| changes, partly because it's
debug only and called from only one place. I probably would have left it alone
just because it leaves the utility method generic, and there would've been more
context as to why IsChild() wouldn't work if the checks were left in the
|DeleteNextInFlowChild()| method.

sr=kin@netscape.com

Please make sure you run the regression tests as well as run some tests
(resizing the window, editing, etc) to exercise this code prior to checkin.
Attachment #101547 - Flags: superreview+
Comment on attachment 101547 [details] [diff] [review]
same patch with aPrevInFlow param removed

r=dcone
Attachment #101547 - Flags: review+
r= alexsavulov (sorry chris, i reviewed it last night and forgot to add the
comment, damn)
The patch is in the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Priority: -- → P2
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.2alpha
can someone with mozilla build please verify this tomorrow and
mark this bug verified-fixed?

thanks.
This bug fixes the crash but not the bad layout; I filed bug 173527 for that.
No longer blocks: 157675
For the record, the nsFirstLetterFrame.cpp changes caused a crash regression in
a testcase that's attached to bug 152755.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: