126807 - Crashes all over in Print Preview [@ nsRenderingContextGTK::GetWidth]

Status: VERIFIED WORKSFORME

(Core :: Print Preview, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

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...

Comment 1

[Samir Gehani]

Nominating.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

[Aleksander Adamowski]

*** Bug 126980 has been marked as a duplicate of this bug. ***

Comment 4

[Aleksander Adamowski]

As I noted in bug 126980 also crashes in MailNews when selecting File->Print and
then clicking 'Cancel'.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Aleksander, that last one is bug 126427, just fixed.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

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) 

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Samir Gehani]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 127132 has been marked as a duplicate of this bug. ***

Comment 10

[kill this account]

Shanjian: thoughts on this?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 12

[Shanjian Li]

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?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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....

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

[Roland Mainz]

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

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 17

[Jan Carpenter]

The most recent crashes from this stack signature in talkback are from the
2002-02-21-14 trunk build.  Fixed perhaps?

Comment 18

[Jay Patel [:jay]]

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.

Comment 19

[sujay]

verified.