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

VERIFIED WORKSFORME

Status

()

Core
Print Preview
P1
critical
VERIFIED WORKSFORME
16 years ago
16 years ago

People

(Reporter: bz, Assigned: rods (gone))

Tracking

({crash, topcrash})

Trunk
mozilla1.0
x86
Linux
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

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

16 years ago
Nominating.
Keywords: nsbeta1
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

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

Comment 4

16 years ago
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) 
Keywords: crash
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

16 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
*** Bug 127132 has been marked as a duplicate of this bug. ***

Comment 10

16 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

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

Comment 15

16 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.
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla1.0

Comment 17

16 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

16 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
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 19

16 years ago
verified.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsRenderingContextGTK::GetWidth]
You need to log in before you can comment on or make changes to this bug.