If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Hang when I print preview a sub page of this website

RESOLVED FIXED in mozilla1.8alpha5

Status

()

Core
Printing: Output
P1
critical
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Clive Norton, Assigned: bz)

Tracking

({hang})

Trunk
mozilla1.8alpha5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

If I try to print preview the location map of the Leeds/Morley centre, Firefox
crashes.

Reproducible: Always
Steps to Reproduce:
1. Open http://mypetstopdenton.co.uk
2. Click "Your nearest centre"
3. Click "MyPetStop Morley"
4. Click "Location Map"
5. Click Print Preview

Actual Results:  
Firefox hangs

Expected Results:  
Preview the image and not hang.

default theme.
nVidia 4200Ti graphics card
drivers 61.77
It happens also to me:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041007
Firefox/0.9.1+
100% cpu, freeze, hang on print preview.
Component: General → Print Preview
Product: Firefox → Browser
Version: unspecified → Trunk
Created attachment 161491 [details]
Testcase

When you do a print preview on this testcase, the browser hangs. 
When you make the middle frame somewhat wider, the browser doesn't hang on
print preview.
(Reporter)

Comment 3

13 years ago
The testcase hangs for me on print preview, too.

Comment 4

13 years ago
With a debug build the following assertion comes up at print preview (before the
hang, which is actually 100% cpu):
###!!! ASSERTION: There must always be an XMost PO!: 'smallestPO', file d:/mozil
la/tree6/mozilla/content/base/src/nsPrintEngine.cpp, line 2396
Stacktrace:
nsSubstring::MutatePrep(unsigned int 0xffffffff, unsigned short * * 0x0012e634,
unsigned int * 0x0012e630) line 81 + 8 bytes
nsSubstring::SetCapacity(unsigned int 0xffffffff) line 507 + 20 bytes
nsSubstring::SetLength(unsigned int 0xffffffff) line 536
nsPageFrame::DrawHeaderFooter(nsPresContext * 0x03d06db8, nsIRenderingContext &
{...}, nsIFrame * 0x04267414, nsPageFrame::nsHeaderFooterEnum eFooter, int
0x00000000, const nsString & {...}, const nsRect & {...}, int 0x000000b4, int
0x000000e1, int 0x0000008d) line 504
nsPageFrame::DrawHeaderFooter(nsPresContext * 0x03d06db8, nsIRenderingContext &
{...}, nsIFrame * 0x04267414, nsPageFrame::nsHeaderFooterEnum eFooter, int
0x00000002, const nsString & {...}, const nsString & {...}, const nsString &
{...}, const nsRect & {...}, int 0x000000b4, int 0x000000e1) line 451
nsPageFrame::Paint(nsPageFrame * const 0x04267414, nsPresContext * 0x03d06db8,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Overlay, unsigned int 0x00000000) line 680 + 90 bytes
PresShell::Paint(PresShell * const 0x0425c0a0, nsIView * 0x0425ed08,
nsIRenderingContext & {...}, const nsRect & {...}) line 5428 + 31 bytes
nsView::Paint(nsView * const 0x0425ed08, nsIRenderingContext & {...}, const
nsRect & {...}, unsigned int 0x00000000, int & 0x00000000) line 338
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x052fcc60,
nsIRenderingContext * 0x0323b940) line 1394
nsViewManager::RenderViews(nsView * 0x04268600, nsIRenderingContext & {...},
const nsRegion & {...}, nsIDrawingSurface * 0x052effd0, const nsVoidArray &
{...}) line 1309
nsViewManager::Refresh(nsView * 0x04268600, nsIRenderingContext * 0x0323b940,
nsIRegion * 0x052fc7a8, unsigned int 0x00000001) line 874
nsViewManager::DispatchEvent(nsViewManager * const 0x04255be0, nsGUIEvent *
0x0012f0d4, nsEventStatus * 0x0012efb8) line 1835

I suspect something is wrong in the last call to nsPageFrame::DrawHeaderFooter,
where it executes
 str.SetLength(indx-3);
indx is 0x00000002 here, which leads to 0xffffffff as argument. Which causes the
loop within " while (temp < capacity)  temp <<= 1;" at the end (capacity is is
the same as indx-3 above and temp is 0x00000000 (at least in my stacktrace, at
the beginning of the loop it's 0x0000003f).
Summary: crash if I print preview a sub page of this website → Hang when I print preview a sub page of this website
Frank, thanks for the excellent analysis!

Reassigning to a reasonable component (someone forgot to push the "reassign"
button earlier too).
Assignee: firefox → core.printing
Status: UNCONFIRMED → NEW
Component: Print Preview → Printing
Ever confirmed: true
Keywords: hang
OS: Windows XP → All
QA Contact: firefox.general
Hardware: PC → All
Created attachment 162160 [details] [diff] [review]
Patch

With this patch, I don't hang anymore...
Comment on attachment 162160 [details] [diff] [review]
Patch

This patch has several changes:

1)  Fix a bug in the doubling algorithm in nsTSubstring_CharT::MutatePrep that
could lead to hangs for legitimate (large) capacities.

2)  Fix the printing code to use Truncate() instead of SetLength(), since that
will assert in cases where a too-big length is passed in.

3) Fix the printing code to not truncate() to -1 or -2 or -3.
Attachment #162160 - Flags: superreview?(darin)
Attachment #162160 - Flags: review?(darin)

Comment 8

13 years ago
Comment on attachment 162160 [details] [diff] [review]
Patch

how about if we just check for "capacity > PR_UINT32_MAX/2" and special case
that instead of mucking with the loop condition?

or maybe we should fail in that case since allocating a 2 GB string buffer is
reasonabley never desired.

Comment 9

13 years ago
Comment on attachment 162160 [details] [diff] [review]
Patch

minusing to get bz's attention ;-)
Attachment #162160 - Flags: superreview?(darin)
Attachment #162160 - Flags: superreview-
Attachment #162160 - Flags: review?(darin)
Attachment #162160 - Flags: review-
I can just bail on capacities that big, sure, if that's what the string API says
about lengths/capacities...

Otherwise, I can do the check for capacity > PR_UINT32_MAX/2, yes.  Which do you
prefer?  I don't really care.

Comment 11

13 years ago
> I can just bail on capacities that big, sure, if that's what the string API 
> says about lengths/capacities...

the string API is not specific about capacity limits.  the older nsString impl
used a couple bits from the capacity field to store other info, so i think it's
fairly safe to assume you won't be breaking binary compat.


> Otherwise, I can do the check for capacity > PR_UINT32_MAX/2, yes.  Which do 
> you prefer?  I don't really care.

i'd prefer to just do one check up front for bogus capacities (i.e., values of
capacity greater than PR_UINT32_MAX/2).
Created attachment 162597 [details] [diff] [review]
Revised per review comments.
Attachment #162160 - Attachment is obsolete: true
Attachment #162597 - Flags: superreview?(darin)
Attachment #162597 - Flags: review?(darin)

Updated

13 years ago
Attachment #162597 - Flags: superreview?(darin)
Attachment #162597 - Flags: superreview+
Attachment #162597 - Flags: review?(darin)
Attachment #162597 - Flags: review+
Assignee: core.printing → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.8alpha5
Fixed.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 14

13 years ago
*** Bug 222618 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
*** Bug 228647 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.