52912 - debugger crash on big image, stack:il_emit_row

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P3)

Description

[Andreas J. Koenig]

Build: this Mozilla was built from fresh CVS sources on 2000-09-15 about 5pm
Pacific time
Reproducability: always
Have I read the MFB page: Yes

I have a real big PNG file lying around: about 12000 x 12000 Pixels and 11MB.

Trying to load this file as a file URL (without HTML involved, directly as .png
file) leads to the following crash message:

Assertion failure: image->haveBits, at scale.cpp:845

Crash happens with and without JavaScript enabled. Same for Java.

I tried to view smaller files and had the following observations with a medium
sized PNG of 3500x3500 pixels and 500kB: My X server and my ssh connection to
the machine where Mozilla is running started to do a lot of work and my 10Mb
ethernet seemed saturated for about half an hour while mozilla-bin used little
to no CPU and increased memory consumption very slowly from 38 to 59MB. The
machine has 512MB and no swapping occurred. Mozilla was mostly unresponsive
during that time. After half an hour Mozilla could be used as a nice Image
viewer on this image, no further annoyances. So I'm running out of ideas what
else I could try to provide some more information.

My X server is 4.0.1. I have produced that image with ImageMagick and have
viewed it with both IM and gimp.

Comment 1

[R.K.Aa.]

A similar bug is 9922, but seems to be about jpg images.

Comment 2

[Peter "jag" Annema]

From a comment on bug 49440:

| ------- Additional Comments From [e-mail] 2000-08-18 11:58 -------
| 
| It would help if the image was attached or the
| test URL was set. There are many ways an image can
| not display.
| 
| Images in the browser are limited to a width&height of
| 8000x8000.

pnunn, does this still hold true?

Andreas, can you put those images online somewhere so we can reproduce this?
Also, what happens when you do use http:// instead of file:// ?

Comment 3

[Andreas J. Koenig]

Attachment: 8001x8001 pixel sized "Hello world" PNG crashes

Comment 4

[Andreas J. Koenig]

The attachment above (id=14859) is only 34k big as it only contains yellow
background and "Hello world" in the upper left corner. My current build crashes
with the already mentioned assertion. Image is produced with ImageMagick like so:

perl -le '
use Image::Magick;
my $im = Image::Magick->new;
$im->Set(size => "8001x8001");
$im->Read("xc:yellow");
$im->Annotate(text=>"Hello world,", x => 100, "y" => 100);
$im->Write("yellow.png");
'

Comment 5

[Andreas Franke (gone)]

I don't see a crash loading the 8001x8001 attachment into Mozilla 2000091606.
After a short time, a "Document ... loaded successfully" msg is shown in the
shell, and the URL (instead of the image itself) is displayed in the Browser.

Comment 6

[Andreas J. Koenig]

Could somebody else try, please? I see currently bugs 52911 and 52912, but
Andreas Franke cannot reproduce either of them. That might indicate some basic
failure in my CVS sources or something.

Comment 7

[Luis Villa]

Andreas K: I see the same results as the other Andreas: no image, but no crash
either, just a file name.

Comment 8

[Andreas J. Koenig]

The bug seems to be the assertion itself. image->haveBits is not allowed outside
of locking regions as is documented in libimg/public/ni_pixmp.h:

    PRBool   haveBits;          /* true if we successfully allocated bits. Can't
just
                                     test the bits ptr directly, because this
pointer
                                     is only really valid between Lock and
Unlock calls
                                     on the pixels of the image */


Consequently, when I remove line 845 from scale.cpp, the crash disappears.

Why nobody else sees the crash is a mystery but I suppose it's pure random luck.

There are a few more tests on ->haveBits in scale.cpp. Maybe they alle need to
be reviewed.

While I was there, I also fixed two warnings. The full, tested patch is now:

--- modules/libimg/src/scale.cpp~       Tue Sep 19 08:42:35 2000
+++ modules/libimg/src/scale.cpp        Tue Sep 19 09:00:30 2000
@@ -833,7 +833,7 @@
     PRUint8 XP_HUGE *dp;
     PRUint8 XP_HUGE *mp;
          PRUint8 XP_HUGE *maskp = NULL;
-    PRUint8 XP_HUGE *alphabits, *alphabitstart = NULL;
+    PRUint8 XP_HUGE *alphabitstart = NULL;
     PRUint8 *byte_mask = NULL;
          PRUint8 XP_HUGE *srcbuf = rgbbuf;
     PRUint8 *p = cbuf;
@@ -842,7 +842,7 @@
     int dcolumn_start, dcolumn_end, column_count, offset, src_len, dest_len;
    
        PR_ASSERT(row >= 0);
-       PR_ASSERT(image->haveBits);             /* we'd better have some bits...
*/
+       /* illegal call as we have not locked
PR_ASSERT(image->haveBits);               /* we'd better have some bits... */
 
        if(row >= (int) src_header->height) {
                ILTRACE(2,("il: ignoring extra row (%d)", row));

Comment 9

[buster]

no doubt about it, crash-city on WinNT, just by loading the 9/16/00 15:20
attachment.  here's the stack:

il_emit_row() line 845 + 42 bytes
ImgDCallbk::ImgDCBHaveRow() line 144 + 50 bytes
row_callback() line 387
png_push_have_row() line 1424 + 39 bytes
png_push_process_row() line 885 + 22 bytes
png_process_IDAT_data() line 739 + 9 bytes
png_push_read_IDAT() line 683 + 23 bytes
png_process_some_data() line 59 + 9 bytes
png_process_data() line 35 + 13 bytes
il_png_write() line 136 + 27 bytes
PNGDecoder::ImgDWrite() line 106 + 20 bytes
IL_StreamWrite() line 1002 + 26 bytes
NetReaderImpl::Write() line 110 + 20 bytes
ImageConsumer::OnDataAvailable() line 443 + 23 bytes
ImageListener::OnDataAvailable() line 155
nsDocumentOpenInfo::OnDataAvailable() line 251 + 46 bytes
nsHTTPFinalListener::OnDataAvailable() line 1191 + 46 bytes
InterceptStreamListener::OnDataAvailable() line 1216
nsHTTPChunkConv::OnDataAvailable() line 211 + 46 bytes
nsHTTPServerListener::OnDataAvailable() line 554 + 67 bytes
nsOnDataAvailableEvent::HandleEvent() line 400 + 47 bytes
nsStreamListenerEvent::HandlePLEvent() line 97 + 12 bytes
PL_HandleEvent() line 580 + 10 bytes
PL_ProcessPendingEvents() line 513 + 9 bytes
_md_EventReceiverProc() line 1049 + 9 bytes
USER32! 77e71820()
00ac51d0()

Comment 10

[buster]

note that this is only a crash in debug builds.  Optimized builds display the
alt text.  On that basis, this should not be nominated for rtm.  You could argue
the loss of data (not being able to display the image) is bad, but I'll leave it
to pam to determine the severity of that.  How big does an png have to be before
it fails to display?

Comment 11

[pnunn]

Our max is 8Kx8K. We shouldn't crash, but 
we can't handle images larger than 8Kx8K.
-p

Comment 12

[Luis Villa]

Should this be marked wontfix and an RFE filed for handling images bigger then
8Kx8K? It seems like it is definitely no longer a crasher, and it seems like the
size-of-image problem isn't really considered a bug at this point. Am I right on
that?

Comment 13

[Andreas J. Koenig]

> it is definitely no longer a crasher

I wouldn't say definitely. I currently do not get Mozilla to work at all, so I
cannot test, but the comments on the code I made on 2000-09-19 seem to have been
ignored so far. No comments made and no changes in the code (afaik)

> size-of-image problem isn't really considered a bug

Isn't an arbitrary restriction to 8000x8000 Pixel a bit ridiculous? And even if
one would accept this restriction, the bahaviour of Mozilla to not inform the
user that they have hit a restriction, just simply display the URL instead, is
definitely weird and will cause this bug to be reopened again and again. (I just
notice, I'm already repeating what Nicholas Cull said on 1999-07-16 in bug 9922)

Comment 14

[Paul Wyskoczka]

Updating QA Contact

Comment 15

[pnunn]

marking rtm-, since crash condition is only in debugger.
Its important but next train should be fine.


-pn

Comment 16

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 17

[Stuart Parmenter]

code no longer used.  marking fixed.  new imagelib can handle images larger 
than 8000x8000 (assuming you have lots of memory)

Comment 18

[Terri Preston]

Hmm, nope, this image crashes mac build 2001052405, crashes xwindows all
together linux build 2001052310 (seems fine on windows)

Comment 19

[Jason Kersey]

-> 0.9.4

Comment 20

[Stuart Parmenter]

fixed.

Comment 21

[Terri Preston]

This image stills freezes my entire w2k machine with build 2001-09-13-05-0.9.4 
crashes linux with build 2001-09-13-05-0.9.4 (incident number 35342053) and 
crashes mac with build 2001-09-13-03-0.9.4

Comment 22

[lchiang]

Please search talkback database to see if it is a topcrash.  per PDT

Comment 23

[Shiva Thirumazhusai]

There is only two incidents in Talkback database with this stack signature.

Comment 24

[Stuart Parmenter]

can we file a new bug on this?  Most of the info (short of the image test case)
is no longer valid.  The stack traces in this bug are no longer valid.

the 8001x8001 image is going to require at least 192MB on windows and 256MB of
memory on mac.  I expect that it didn't actually crash your machine (on windows
at least)... it was probably just thinking *really* hard..

Comment 25

[Jay Patel [:jay]]

Terri - When you log a new bug, can you try to reproduce this again and get the
Talkback incident ids for all your crashes?  It will help in the future if we
have a new stack trace and the incident ids...so we can check if others are
seeing what you are. Thanks.

Comment 26

[Terri Preston]

Mac build 2001-09-13-03-0.9.4 crash is incident 35393202, can't get one on 
windows, crashes my whole machine and I have reboot 

Comment 27

[Asa Dotzler [:asa]]

0.9.4 is out the door

Comment 28

[Stuart Parmenter]

is there a new bug for this yet?

Comment 29

[Stuart Parmenter]

re-marking fixed for 0.9.3.  filed bug 100250 to represent the "new" code 
problem for the crash since none of the stacks or other info is valid (except 
the test case itself.

Comment 30

[Terri Preston]

Sounds good to me, marking verified