263365 - Hang when I print preview a sub page of this website

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P1)

Description

[Clive Norton]

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

Comment 1

[Martijn Wargers (dead)]

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.

Comment 2

[Martijn Wargers (dead)]

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

Comment 3

[Clive Norton]

The testcase hangs for me on print preview, too.

Comment 4

[Frank Wein [:mcsmurf]]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

Frank, thanks for the excellent analysis!

Reassigning to a reasonable component (someone forgot to push the "reassign"
button earlier too).

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

With this patch, I don't hang anymore...

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Darin Fisher]

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

[Darin Fisher]

Comment on attachment 162160 [details] [diff] [review]
Patch

minusing to get bz's attention ;-)

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[Darin Fisher]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Revised per review comments.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 14

[James Napolitano]

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

Comment 15

[Christian Franke]

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