377634 - Painting random pixels for a large GIF image, when at the end of a line

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Mats Palmgren (inactive)]

STEPS TO REPRODUCE
1. load the attached testcase
2. resize the window

ACTUAL RESULT
Looks like we're painting random memory

EXPECTED RESULT
The image should look like a flag, it looks correct when making the window
narrow.

PLATFORMS AND BUILDS TESTED
Bug occurs in Minefield 20070415 on Linux
Bug occurs in a SeaMonkey debug build on Linux
Bug does NOT occur in Firefox 2.0.0.3 on Linux

Comment 1

[Mats Palmgren (inactive)]

Attachment: The image

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 3

[Mats Palmgren (inactive)]

Attachment: Screenshot of error

Comment 4

[Mats Palmgren (inactive)]

FYI, the 'file' command on Linux for this image:
GIF image data, version 89a, 10000 x 6132

Comment 5

[Steve England [:stevee]]

Due to cairo? (Bug 323923)

Certainly, I see no issues with
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060222
Firefox/1.6a1 ID:2006022209 (Pre-cairo)

But I do with:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060223
Firefox/1.6a1 ID:2006022314 (Post-cairo)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-22+08&maxdate=2006-02-23+15&cvsroot=%2Fcvsroot

(I also see other issues with the post-cairo build, namely an inordinate amount of time and memory used to decode the image, but that was fixed later in other bugs).

Comment 6

[Daniel Holbert [:dholbert]]

I tried out a few testcases with various zoomed versions of the flag image and of the Google logo.  For those images, the bug only occurs when the img tag's "width" field is less than 2.6% of the image's actual width.

It's also not restricted to GIFs -- I reproduced it with both JPEG and PNG images.

Comment 7

[Daniel Holbert [:dholbert]]

The guilty line is:
http://mxr.mozilla.org/seamonkey/source/gfx/src/thebes/nsThebesImage.cpp#395
> mat.Translate(-destRect.pos);

In the buggy test cases, this line is pushing mat.x0 lower than the signed integer boundary of -32768.  A value of -32768 gives correct behavior, whereas -32769 and below gives the buggy behavior.

Comment 8

[Daniel Holbert [:dholbert]]

Here's an explanation for why we're getting such large numbers.

From what I understand of the code and the test case I've been using, we're placing an image at an x-position of about 700 pixels over on the page. (this is destRect.pos.x)  Moreover, the image is scaled down horizontally by 50 times. (this value is stored in mat.xx).  The "Translate" call mentioned above results in a computation of ~ 50 * -700 = -35000, to get a value in terms of original-image-pixels.  And sadly, this value is outside the range of a signed integer.

I'm still not sure where specifically we try to store this out-of-bounds value in a signed integer, but it's got to be somewhere in the last few lines of nsThebesImage::Draw, after the aforementioned call to Translate.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #7)
> signed integer boundary of -32768.

Oops -- by "signed integer," I meant "signed short".

Comment 10

[Boris Zbarsky [:bzbarsky]]

vlad, didn't you recently send mail to the cairo list about this sort of thing?

Comment 11

[Daniel Holbert [:dholbert]]

This bug looks fixed to me.  Can we close this?

Comment 12

[Stuart Parmenter]

i like closing bugs!  WORKSFORHOLBERT