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...
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?
*** Bug 126980 has been marked as a duplicate of this bug. ***
As I noted in bug 126980 also crashes in MailNews when selecting File->Print and then clicking 'Cancel'.
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)
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.
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.
*** Bug 127132 has been marked as a duplicate of this bug. ***
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).
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?
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....
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....
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.
The most recent crashes from this stack signature in talkback are from the 2002-02-21-14 trunk build. Fixed perhaps?
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.