The browser seems to be crashing about mid-way through the loading of "main.php" (http://www.brogdon.net/~darrell/main.php). If you load this page directly (i.e. not within the frames) it doesn't crash the browser. However, its when you load the full page (http://www.brogdon.net/~darrell/) that it crashes the browser. I've only noticed this on the above site so far but if its happening with my site I'm sure its happening somewhere else. I have confirmation from other people that it is crashing their version of Mozilla as well. I'm using Build ID: 2000091808 and I've noticed this happening for about a week now.

Wfm on 091905 Win32. Please confirm on Linux.

OK, this crahses me on linux but not on win32 or mac 091908 builds. Need a stack trace.

I see the crash on Linux 2000-09-18-08. I could create a reduced testcase. To reproduce the crash: 1) save the first attachment, a reduced version of frm_main.php 2) save the second attachment, a reduced version of header.php 3) download http://www.brogdon.net/~darrell/images/hdr_delimiter.png and save it as hdr_delimiter.png. These 3 files must be in the same directory. 4) load frm_main.php into mozilla I've tried with a gif instead of a png and did not crash. I've also tried to put the image's full URL in header.php and it did not crash. Also if the path in header.php is not valid (does not point to a file) it does not crash. Imagelib? Marking confirmed, adding crash and testcase keywords.

could be parser or imagelib. could you post the full testcase on a server perhaps? not everyone has php running on linux.

I don't have php running. These files are just plain html so you should be able to reproduce by just saving them on a local filesystem.

updating component and setting default owner.

Verified that this does not crash on Win32 (but crashes every time on Linux). Also verified that if the image is replaced with a GIF it works fine on Linux and Win. I tried another PNG and did not get a crash (though the other PNG I tried did not display at all on Win or Linux - maybe this is an unrelated bug) Based on the stack, and the fact that the crash is only on GTK, I'm guessing that this is not imagelib. Handing over to the local GTK guru...

I believe this is bug 52275, tor's bug for crash with certain images on Linux (top of stack is #0 0x410b8dc3 in nsImageGTK::DrawComposited () #1 0x410a9f09 in nsImageGTK::Draw () #2 0x410afd9f in nsRenderingContextGTK::DrawImage () ...) *** This bug has been marked as a duplicate of 52275 ***

Same stack traces, plus now that 52275 has been fixed this page renders fine in Linux build 2000110721: Verified dupe.