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)
Core
Printing: Output
Tracking
()
RESOLVED
FIXED
mozilla1.2alpha
People
(Reporter: fleuenb, Assigned: karnaze)
References
()
Details
(Keywords: crash, hang, regression)
Attachments
(3 files, 2 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
application/zip
|
Details | |
(deleted),
patch
|
dcone
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 1•22 years ago
|
||
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]
Updated•22 years ago
|
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
Comment 4•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
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
Comment 7•22 years ago
|
||
this is a regression from bug 145305
Depends on: 145305
Keywords: regression
Comment 8•22 years ago
|
||
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.
Assignee | ||
Comment 9•22 years ago
|
||
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.
Assignee | ||
Comment 10•22 years ago
|
||
Changed DeleteNextInFlow() to DeleteNextInFlowChild().
Attachment #101488 -
Attachment is obsolete: true
Comment 12•22 years ago
|
||
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 13•22 years ago
|
||
Comment on attachment 101547 [details] [diff] [review] same patch with aPrevInFlow param removed r=dcone
Attachment #101547 -
Flags: review+
Comment 14•22 years ago
|
||
r= alexsavulov (sorry chris, i reviewed it last night and forgot to add the comment, damn)
Assignee | ||
Comment 15•22 years ago
|
||
The patch is in the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Priority: -- → P2
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.2alpha
Comment 16•22 years ago
|
||
can someone with mozilla build please verify this tomorrow and mark this bug verified-fixed? thanks.
Assignee | ||
Comment 17•22 years ago
|
||
This bug fixes the crash but not the bad layout; I filed bug 173527 for that.
Comment 18•22 years ago
|
||
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.
Description
•