Closed Bug 21178 Opened 25 years ago Closed 25 years ago

[PP][DOGFOOD][REGRESSION]Printing causes a crash

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: nbaca, Assigned: sspitzer)

References

Details

(Whiteboard: [PDT+]fix in hand, checking in ASAP)

Attachments

(1 file)

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.
*** Bug 21179 has been marked as a duplicate of this bug. ***
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.
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
Whiteboard: [PDT+]
Putting on the PDT+ radar.
Assignee: dcone → syd
can you check this out... what is happening here. I am sure its not printing.. something else must be happening...
Priority: P3 → P1
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;
Added rickg to CC, this is in layout.
Whiteboard: [PDT+] → [PDT+][Estimated date 12.17]
Status: NEW → ASSIGNED
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.
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.
*** Bug 12495 has been marked as a duplicate of this bug. ***
Assignee: syd → sspitzer
Status: ASSIGNED → NEW
helping out, re-assign to me for now.
dup of 19148 too?
Target Milestone: M12
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.
Still crash on 12-13-08-M12 Linux build for printing.
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.
It's not crashing there for me. I inserted some printfs, and it's making it past the mLastFont = mNormalFont; statement.
erik, you can print on linux?
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.
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?
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.
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.
Status: NEW → ASSIGNED
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.
Whiteboard: [PDT+][Estimated date 12.17] → [PDT+]fix in hand, seeing review and approval
updating summary
The fix looks good. Thanks. And sorry about the trouble...
Whiteboard: [PDT+]fix in hand, seeing review and approval → [PDT+]fix in hand, checking in ASAP
syd and erik reviewed, chofmann approved, checking in soon.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Linux Redhat 6.0 (1999-12-14-11 M12) Printing on LInux does not crash any more.
Blocks: 22176
No longer blocks: 22176
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: