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.

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

From a comment on bug 49440: | ------- Additional Comments From pnunn@netscape.com 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:// ?

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"); '

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.

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.

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

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

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

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?

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

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?

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

Updating QA Contact

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

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

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

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

-> 0.9.4

fixed.

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

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

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

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

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.

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

0.9.4 is out the door

is there a new bug for this yet?

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.

Sounds good to me, marking verified