Mozilla crashes while loading the page of PNG test icons located at: http://www.cdrom.com/pub/png/pngsuite.html

I am seeing the crash on xlfn0g04.png. but I expect I could see it on xcrn0g04.png. Both have been corrupted. The browser shouldn't crash even if the image has garbage in it.

Same thing happens in nglayout viewer.exe

All the viewers use the same image decoding code.

I've managed to track down and fix this bug. This fix consists of two parts: 1. A replacement file for ipng.cpp in the imglib, available at: http://www.geocities.com/SiliconValley/Haven/8120/ipng_cpp.txt 2. A patch for the file for nsImageNetContextAsync.cpp in gfx, available at: http://www.geocities.com/SiliconValley/Haven/8120/img_diff.txt

Setting all current Open Critical and Major to M3

[adding self as QA contact]

I just tested today's release build on xlfn0g04.png and xcrn0g04.png and gecko doesn't crash. Neither are they displayed (they are corrupted pngs and shouldn't display) but the broken image icon should display and it doesn't. Not a M3 problem, but M6. -pnunn

I justed tested this problem with the 4/2/99 build and it still crashes on the above url under Windows 95. My DOS Window (see below) says PNG file corrupted. ==DOS WINDOW ====================================== FindBookmarkShortcut: in='http://www.cdrom.com/pub/png/pngsuite.html' out='' URL to load in nsBrowserAppCore is http://www.cdrom.com/pub/png/pngsuite.html nsMessengerNameSet::AddNameSet() Registering Messenger in the JS namespace nsComposerNameSet::AddNameSet() Registering Composer in the JS namespace nsMessengerNameSet::InitializeClasses() Initializing base classes nsComposerNameSet::InitializeClasses() Initializing base classes libpng error: PNG file corrupted by ASCII conversion ======================================== APPRUNNER caused an invalid page fault in module MSVCRT.DLL at 014f:78001230. Registers: EAX=0086f9f0 CS=014f EIP=78001230 EFLGS=00010246 EBX=00880034 SS=0157 ESP=0076fac8 EBP=0076fae8 ECX=00000002 DS=0157 ESI=ffffffff FS=4daf EDX=04bfc16c ES=0157 EDI=00873a08 GS=0000 Bytes at CS:EIP: 89 79 08 0f 84 07 01 00 00 8b 4d f4 8b 7c f1 04 Stack dump: 000000b4 000000b4 04bd3800 bff798a5 000000c0 008739b0 00000000 0000001f 0076fb44 7800140e 00880034 00000009 000000b4 04bfaa50 780013e9 000000b4

asdf

Greg: Would you take a look at this one? It looks like the crash occurs when we try to free up png_ptr->zbuf when its a garbage ptr. The test in the free is for NULL and so it happily continues on its crashing way. The code in png_create_struct() isn't catching the error that occurs when the structure is allocated. The first image crashing is xlfn0g04.png. there may be more, but this image is the first one. I've changed the URL, so it points to the bad png.

Pamela, The problem is simply that the error handler was never set up before calling png_process_data() in ipng.cpp. longjmp() gets called and goes off to who knows where, eventually segfaulting. Here's a short patch that fixes just this one problem (stupid attachment option didn't work and lost my first message, sigh): *** ipng.cpp.stock Sat Jul 3 11:04:16 1999 --- ipng.cpp Sat Jul 3 11:22:14 1999 *************** *** 114,119 **** --- 114,123 ---- } /* note addition of ic to png structure.... */ png_ptr->io_ptr = ic; + if (setjmp(png_ptr->jmpbuf)) { + png_destroy_read_struct(&png_ptr, &info_ptr, NULL); + return !OK; + } png_process_data( png_ptr, info_ptr, (unsigned char *)buf, len ); ipng_ptr->state = PNG_CONTINUE; Note, however, that I'm rewriting much of the PNG code and should be done with that later today; I'll send you the (large) patch separately. If you're around today (3 July), send me some e-mail--even with the patch above, il_png_write() gets called a second time, and I haven't yet figured out why.

Thanks Greg. I'll check this is as soon as the tree opens. -pn

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

fix checked in 07-07-99. -pn

On Win32, Linux and Mac OS (7.9.99 PM build), a crash no longer takes place; instead, a dot appears where the image file name should appear. I'm going to investigate this further after M8 is finished, and either re-open or break out a new bug.

Verifying as fixed; side-issue broken into 9796.

Linux build from 2000-04-14 sourceball is crashing (segfault) on corrupted PNG images again. The first of these pages has three bad images inlined (including the one given above), while the second only has links to them and doesn't cause a crash: http://www.cdrom.com/pub/png/pngsuite.html http://www.cdrom.com/pub/png/pngsuite-all-good.html It appears that the libpng-related error-handling code in ipng.cpp is working correctly, returning control to il_png_write() via a longjmp(). That function then sets the state to PNG_ERROR and passes an error value to whatever called it. But apparently something upstream is ignoring the error value once again and subsequently returns control to ipng.cpp, which no longer has a valid PNG (libpng) context.

reassigning to owner; leaving priority and severity alone

adding regression and crash keywords

have fix. waiting for open tree. -p

checked in. -p

Verified fixed (doesn't crash) using this morning's builds on Mac, Win & Linux.

Not fixed. It doesn't crash immediately upon loading the page, as it did before, but today's "nightly" for Linux/glibc segfaults as soon as you scroll down to where the bogus images are inlined.

Oddly enough, no crash occurs on today's Win32 nightly. But no "broken image" icons are displayed, either.

Eli: Would you check this again. Chances are Greg was misinterpreting another class of error. Closing as fixed to put on your radar. -P

The http://www.cdrom.com/pub/png/pngsuite.html page displays on today's Win/Mac/ Linux builds with no crash. Verifying.