Closed
Bug 21178
Opened 25 years ago
Closed 25 years ago
[PP][DOGFOOD][REGRESSION]Printing causes a crash
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: nbaca, Assigned: sspitzer)
References
Details
(Whiteboard: [PDT+]fix in hand, checking in ASAP)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Build 1999120808M12: Linux/Redhat 6.0
Overview: Printing causes a crash
Steps to reproduce:
1. Launch the browser
2. Using the default page (or another page such as "www.netmanage.com") select
File/Print
Actual Results: The application crashes.
Expected Results: The application should not crash and should print what is
selected.
Additional Information:
1. Mail also crashes in Linux when printing a simple text message.
2. It also crashes when selecting the Print button.
3. The Mac build prints without a crash.
Haven't tried the Windows build because it is not available yet.
Comment 2•25 years ago
|
||
Do you have a stack trace, anything that might narrow what is going on.
I don't have a linux box so anything that might help would be appreciated.
Comment 3•25 years ago
|
||
dcone, I reproduced this crash in the linux debugger. But for some reason only
one frame was showing up.
It's crashing in nsTextFrame::TextStyle::TextSTyle in nsTextFrame.cpp at line 423.
(This is from my linux build which was pulled last night around 9pm)
Severity: major → critical
Summary: [PP]Printing causes a crash → [PP][DOGFOOD][REGRESSION]Printing causes a crash
Updated•25 years ago
|
Assignee: dcone → syd
Comment 5•25 years ago
|
||
can you check this out... what is happening here. I am sure its not printing..
something else must be happening...
Crashing in reflow.
#0 nsSimplePageSequenceFrame::Reflow (this=0x86d05e4, aPresContext=0x86c0970,
aDesiredSize=@0xbfffd138, aReflowState=@0xbfffd090, aStatus=@0xbfffd354)
at nsSimplePageSequence.cpp:237
#1 0x40fe7675 in nsContainerFrame::ReflowChild (this=0x86d05a8,
aKidFrame=0x86d05e4, aPresContext=0x86c0970, aDesiredSize=@0xbfffd138,
aReflowState=@0xbfffd090, aX=0, aY=0, aFlags=0, aStatus=@0xbfffd354)
at nsContainerFrame.cpp:621
#2 0x4102ecd5 in ViewportFrame::Reflow (this=0x86d05a8,
aPresContext=0x86c0970, aDesiredSize=@0xbfffd324,
aReflowState=@0xbfffd280, aStatus=@0xbfffd354) at nsViewportFrame.cpp:526
#3 0x4101886d in PresShell::InitialReflow (this=0x849a090, aWidth=11520,
aHeight=14400) at nsPresShell.cpp:1114
#4 0x412032eb in DocumentViewerImpl::Print (this=0x82ff488)
at nsDocumentViewer.cpp:1094
The function at the top of the above stack goes into a look, reflowing children.
The first child for which Reflow is called causes the crash. I'm out of time
tonight to trace into it but looks like that stack gets whacked pretty good.
Here is the debugger output after stepping over that call to Reflow (on line 245
below)
(gdb) n
240 pageSize, reflowReason);
(gdb) list
235 // Tile the pages vertically
236 nsHTMLReflowMetrics kidSize(nsnull);
237 for (nsIFrame* kidFrame = mFrames.FirstChild(); nsnull != kidFrame; ) {
238 // Reflow the page
239 nsHTMLReflowState kidReflowState(aPresContext, aReflowState, kidFrame,
240 pageSize, reflowReason);
241 nsReflowStatus status;
242
243 // Place and size the page. If the page is narrower than our
244 // max width then center it horizontally
(gdb) n
245 ReflowChild(kidFrame, aPresContext, kidSize, kidReflowState, x, y, 0,
status);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
nsTextFrame::TextStyle::TextStyle (this=0x0, aPresContext=0x0,
aRenderingContext=@0x0, sc=0x0) at nsTextFrame.cpp:423
423 mLastFont = mNormalFont;
Could we test this again to make sure it is still happening? I heard that troy
checked in some cleanup code that has a better than zero chance of clearing up
this problem. If still a problem, I will work at getting a purify build up to
see if there are any memory bounds type of errors that may be leading to the
crash.
Comment 9•25 years ago
|
||
I still see this on today's linux verification build (1999121008). open the
browser, hit print, click ok in the linux print dialog, and it crashes.
Comment 10•25 years ago
|
||
*** Bug 12495 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Assignee: syd → sspitzer
Status: ASSIGNED → NEW
Assignee | ||
Comment 11•25 years ago
|
||
helping out, re-assign to me for now.
Comment 12•25 years ago
|
||
dup of 19148 too?
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12
Assignee | ||
Comment 13•25 years ago
|
||
marking m12.
Comment 14•25 years ago
|
||
Perhaps a duplicate of the bug chofmann mentions although the other bug is also
against the Mac as stated in the summary (when the other bug was reopened, the
person didn't state whether the crash was also on Mac). This bug report is on
Linux.
Comment 15•25 years ago
|
||
Still crash on 12-13-08-M12 Linux build for printing.
Assignee | ||
Comment 16•25 years ago
|
||
the 1999-12-07-08-M12 build can print, but the 1999-12-08-08-M12 crashes.
looking at the check ins, and given that the crash happens at line 427 in
nsTextFrame.cpp:
aPresContext->GetMetricsFor(*plainFont, &mNormalFont);
aRenderingContext.SetFont(mNormalFont);
boom->aRenderingContext.GetWidth(' ', mSpaceWidth);
mLastFont = mNormalFont;
I think this may to do with erik's font checkins. investigating more now, will
try to find erik to ask for help.
Comment 17•25 years ago
|
||
It's not crashing there for me. I inserted some printfs, and it's making it
past the mLastFont = mNormalFont; statement.
Assignee | ||
Comment 18•25 years ago
|
||
erik, you can print on linux?
Comment 19•25 years ago
|
||
No, I can't print. It does crash. I inserted printfs to check whether it was
crashing near the font code. It wasn't. I don't know where it is crashing tho.
Comment 20•25 years ago
|
||
My tree isn't up to date, though. And it has some modifications. I'll try a new
pull. Are you sure that it's crashing at the GetWidth call?
Assignee | ||
Comment 21•25 years ago
|
||
the crash is weird...the stack is usually bogus. it's got one call on it, like
this:
nsTextFrame::TextStyle::TextStyle (this=0x0, aPresContext=0x0,
aRenderingContext=@0x0, sc=0x0) at nsTextFrame.cpp:423
I'm going to try backing out changes to see if I can narrow it down.
Comment 22•25 years ago
|
||
I'm positive it is. I have been able to obtain a stack just prior to that call.
Stepping into/over it causes the crash and the stack gets totally slammed as a
result. I can work on posting instructions for setting up breakpoints that
efficiently lead you to that point if you are interested.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 23•25 years ago
|
||
fix in hand!
the problem got fixed when I listened to the warnings.
when erik made his checkin, he added another GetMetricsFor()
with a different signature.
this caused the following warnings, because we never added
the new GetMetricsFor() to nsDeviceContextPS.(cpp|h)
here was the warning:
nsDeviceContextPS.h:77: warning: by `nsDeviceContextPS::GetMetricsFor(const
nsFont &, nsIFontMetrics *&)'
nsIDeviceContext.h should really been generated from idl, because if it was,
we would have found that you can't express foo(a) and foo(a,b) as methods
to an interface. You would have had to had foo(a) and foo2(a,b), but then
it would have failed to compile.
I'll paste the fix next for erik / dcone to review.
Assignee | ||
Comment 24•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+][Estimated date 12.17] → [PDT+]fix in hand, seeing review and approval
Assignee | ||
Comment 25•25 years ago
|
||
updating summary
Comment 26•25 years ago
|
||
The fix looks good. Thanks. And sorry about the trouble...
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+]fix in hand, seeing review and approval → [PDT+]fix in hand, checking in ASAP
Assignee | ||
Comment 27•25 years ago
|
||
syd and erik reviewed, chofmann approved, checking in soon.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•25 years ago
|
||
fixed.
Comment 29•25 years ago
|
||
Linux Redhat 6.0 (1999-12-14-11 M12)
Printing on LInux does not crash any more.
You need to log in
before you can comment on or make changes to this bug.
Description
•