Version:2000040709 Platforms: Mac Other Platforms: Need to try on Win 98 and Linux. Expected Results: The image should be rendered and displayed in the browser window. What I got: As images is rendered, the application crashes. Steps to reproduce: 1) Load the following url:http://members.home.com/chowten/Bd_page 2) A table is displayed conatining images. 3) Click on the image in the first cell (of the first column). 4) This will load the full 640 x 480 image in the window. After the image is rendered, press the back arrow icon to see table again. 5) Click on the image in the second cell (of the first column). 6) The image begins to render but crashes.

Eli, I believe this bug may be related to bug 30060. But I couldn't reproduce that problem last time I tried.

Adding crash keyword.

I don't see the problem on NT. I do see it on mac. -P

Putting on [nsbeta2+] radar for beta2 fix.

Notes: I can make the crash happen consistantly by : loading the image files locally as well as from the server : they don't need to be in a table. : the crash doesn't occur on all images, only one or two. Putting other jpgs in a similar table with similar links doesn't cause the crash. It seems the crash is specific to a few of the jpegs and is not related to the page or the way the image is retrieved from the server. -P

Updated link. -p

Update on bug: Some other jpeg app's can't read two of the image files on this page. The 2 files I have been using in the test are: http://members.home.com/chowten/easter_pictures/David_with_presents.JPG http://members.home.com/chowten/easter_pictures/Going_to_brunch.JPG Attempting to view these images with mac jpegview, version 3.3, gives a warning message (Unsupported SOF marker type 0xc2 which is for progressive Huffman) and is unable to display the image. Mac Quicktime 3.0 has no problem displaying the images. However Windows Quicktime version 2.1.2.59 can't display the images. Photoshop 5.5 has no problem with either of the images. Whether the image is displayed or not, we should not crash. My current theory is that in decoding the image, our buffers are not large enough to hold data until we get the header info we need. Its possible that the data is thrown to the decompressor before we enough header info. -P

I just found a reference that says apps that don't support progressive jpegs often give messages like the one given by mac jpegview. The browser does support progressive jpeg, but I suspect the buffer size is related to the crash. -P

Bug Update: Guessing that the crash is due to a buffer overrun, or an unsuccessful allocation that is used even though it was not successfully allocated, I put breakpoints in the memory allocation portions of jpeg.cpp. Through these I was able to track down the crash to jpeg_open_backing_store() in jmemansi.c, which is called when the memory manager allocates virtual arrays. The crash occurs in tmpfile() part of NSStdLib, file_io.c. Remember that the crash only happens on the mac, so it looks like the problem is in the mac implementation of tmpfile() or some part of the use of it. -P

Bad new here. Looks like this bug is actually a bug in the stdlib tmpfile() implemented on the mac. Refer to bug #41360. I have to mark this bug dependent on bug#41360. I will try to find a work around for the problem.

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

I just tested this with Simon's patch described in bug#41360 for tmpfile() in nsStdLib. It works great. The crash was due to the error in tmpfile in nsStdLib. This bug can be closed.

Hurray ! I would to check for the fix in the next mac build. Will tomorrow's build have the fix ?

The trick is....the release build must have the stdlib patch for file_io.mac.c. I'm pretty sure that Simon put the patch on the build machines. (and that he contacted Apple about their bug.) -P

Fixed in the June 15th Mac build (2000061508).

fixing null OS field