Closed
Bug 126807
Opened 23 years ago
Closed 23 years ago
Crashes all over in Print Preview [@ nsRenderingContextGTK::GetWidth]
Categories
(Core :: Print Preview, defect, P1)
Tracking
()
VERIFIED
WORKSFORME
mozilla1.0
People
(Reporter: bzbarsky, Assigned: rods)
References
Details
(Keywords: crash, topcrash)
Crash Data
BUILD: Linux 2002-02-20-08 STEPS TO REPRODUCE: 1) Open print preview 2a) Click "Page Setup...." 3a) Click "Cancel" 2b) Click the "Landscape" button 2c) Decrease the zoom scale by 3% EXPECTED RESULTS (for all 3): Not crash ACTUAL RESULTS: Crash My debug tree is building; I'll try to get some stack traces up tonight. I suspect these are all the same bug...
Reporter | ||
Comment 2•23 years ago
|
||
OK, debug builds crash on opening print preview (bug 126929 filed). I got a talkback build, though. Incident ids: Clicking cancel: TB3180154G Clicking landscape: TB3180142W Zooming: TB3180110K Stephend, could you check out the stacks and attach all the distinct ones here?
Comment 3•23 years ago
|
||
*** Bug 126980 has been marked as a duplicate of this bug. ***
Comment 4•23 years ago
|
||
As I noted in bug 126980 also crashes in MailNews when selecting File->Print and then clicking 'Cancel'.
Reporter | ||
Comment 5•23 years ago
|
||
Aleksander, that last one is bug 126427, just fixed.
all stacks are exactly the same: nsRenderingContextGTK::GetWidth() nsRenderingContextGTK::GetWidth() nsPageFrame::DrawHeaderFooter() nsPageFrame::DrawHeaderFooter() nsPageFrame::Paint() PresShell::Paint() nsView::Paint() nsViewManager::RenderDisplayListElement() nsViewManager::RenderViews() nsViewManager::Refresh() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWindow::DoPaint() nsWindow::Update() nsWindow::UpdateIdle() libglib-1.2.so.0 + 0x11149 (0x40371149) libglib-1.2.so.0 + 0x10186 (0x40370186) libglib-1.2.so.0 + 0x10751 (0x40370751) libglib-1.2.so.0 + 0x10804 (0x40370804) nsAppShell::DispatchNativeEvent() nsXULWindow::ShowModal() nsWebShellWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJS() nsWindowWatcher::OpenWindow() nsPromptService::DoDialog() nsPromptService::Alert() nsPrompt::Alert() DocumentViewerImpl::ShowPrintErrorDialog() PrintData::~PrintData() DocumentViewerImpl::InstallNewPresentation() DocumentViewerImpl::PrintPreview() XPTC_InvokeByIndex() XPCWrappedNative::CallMethod() XPC_WN_CallMethod() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsViewManager::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x1753b (0x4034053b) libglib-1.2.so.0 + 0x10186 (0x40370186) libglib-1.2.so.0 + 0x10751 (0x40370751) libglib-1.2.so.0 + 0x108f1 (0x403708f1) libgtk-1.2.so.0 + 0x8ac69 (0x40294c69) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x4049a9cb)
Keywords: crash
Reporter | ||
Comment 7•23 years ago
|
||
OK... the Crash is in nsRenderingContextGTK::GetWidth(const PRUnichar* aString, PRUint32 aLength, nscoord& aWidth, PRInt32* aFontID) I put in the following printf right at the beginning of the |while (font < end)| loop: fprintf(stderr, "Current font: %p, diff %d, num %d, deref %p\n", font, end - font, metrics->mLoadedFontsCount, *font); Typical output: Current font: 0x858d438, diff 1, num 1, deref 0x876d4d0 Output from right before the crash: Current font: 0x8241438, diff 2173, num 2173, deref 0x401bac00 That last value is pretty bogus-looking to me -- it looks like a stack-range value, not a heap-range value. The fact that the mFontMetrics claims to have 2173 fonts is also a little odd.
Keywords: mozilla0.9.9
Comment 8•23 years ago
|
||
Over to Rod on the assumption this is a backend bug. If this isn't a backend bug, please advise if the page setup and/or print preview front end are behaving badly (using the wrong print settings or some such) and reassign back to us if that is the case.
Assignee: sgehani → rods
Reporter | ||
Comment 9•23 years ago
|
||
*** Bug 127132 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
Shanjian: thoughts on this?
This is one of the top few topcrashes for the past 2 days (based on XP totals) and by far the #1 topcrash on Linux for the past 2 days (2-20 and 2-21).
Keywords: topcrash
Summary: Crashes all over in Print Preview → Crashes all over in Print Preview [@ nsRenderingContextGTK::GetWidth]
Comment 12•23 years ago
|
||
metrics->mLoadedFonts should not have 2173 loaded fonts there. It looks like "metrics" is corrupted or uninitialized. Did anyone check in anything related to print font resolving recently?
Reporter | ||
Comment 13•23 years ago
|
||
The plot thickens. I can now no longer reproduce the crash in my build. Backing out the patch in bug 126803 makes the problem reappear, however. So it looks like something was not handling a failure return very well....
Reporter | ||
Comment 14•23 years ago
|
||
So, here's the sequence of events that led to the crash: 1) DocumentViewerImpl::InstallNewPresentation calls |delete mOldPrtPreview;| (only when mIsDoingPrintPreview is set). 2) The destructor for PrintData calls EndDocument() 3) The EndDocument() call returns an error 4) The destructor tries to put up an error alert 5) We try to update the window under the alert and crash If I move the code that deletes mOldPrtPreview to right after we disable the viewmanager refresh, then everything is OK (well, the window doesn't refresh as I move the alert about but also does not crash). If I put the deletion of mOldPrtPreview after refresh is re-enabled but also after we have called mDeviceContext->SetUseAltDC(kUseAltDCFor_FONTMETRICS, PR_FALSE); Then everything is peachy as well. So it looks like at this point the alternate device context is just not with it anymore. The patch in bug 126803 eliminated step (3) in my steps, but if some platform ever has a legitimate error in EndDocument() in these circumstances....
Comment 15•23 years ago
|
||
bz: Can you check whether the patch in bug 127627 ("Print preview wants to use more than one print device context in some cases") fixes this ? If yes we may have one of these more-then-one-print-device-context-causes-havoc-issues.
Comment 16•23 years ago
|
||
Marking nsbeta1+
Comment 17•23 years ago
|
||
The most recent crashes from this stack signature in talkback are from the 2002-02-21-14 trunk build. Fixed perhaps?
Comment 18•23 years ago
|
||
Marking this worksforme since we don't know for sure if some other checkin fixed this crash. According to Talkback data, this crash last occurred with MozillaTrunk builds from 2/21. Please reopen if this is reproduced with a more recent build.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ nsRenderingContextGTK::GetWidth]
You need to log in
before you can comment on or make changes to this bug.
Description
•