GNOME Bugzilla – Bug 138238
jpeg plug-in crashes when opening file
Last modified: 2004-04-05 18:05:56 UTC
Open the attached jpeg file (picture of my son take with Kodak Digital Camera) Gimp 2.0.0 is unable to create a preview or open the image. Attempting to open the image causes jpeg.exe to crash and gimp to report error in jpeg plug-in. Windows XP SP1 using Gimp 2.0.0 Installed gimp from http://www2.arnes.si/~sopjsimo/gimp/stable.html GTK+ 2 version 2.2.4-20040124 Also, installed previously, have gimp 1.2.5 on the machine which _is_ able to open the image.
Created attachment 25988 [details] picture of my son taken with kodak 2MP digital camera in grocery store
I think I found the difference. The original photos taken with the camera work fine. Once I've uploaded them with OfotoNow software, they cause the crash. It appears that ofotonow edits properties of the original image once it has been uploaded, specifically the software property. I'll attach a before and after photo.
Created attachment 25989 [details] Before uploading with ofoto - picture of my cat
Created attachment 25990 [details] After Uploading with ofoto - same picture of my cat
I can reproduce this bug on WinXP using Jernejs installer. All three photos open fine in current CVS HEAD on Linux, though. I ran 'file' on the three JPEGs: brix@fungoid tmp $ file *.jpeg after.jpeg: JPEG image data, EXIF standard 0.73, 10752 x 2048 before.jpeg: JPEG image data, EXIF standard 0.77, 42 x 0 son.jpeg: JPEG image data, EXIF standard 0.73, 10752 x 2048 It appears that the two JPEGs which causes the jpeg plug-in to crash on win32 conforms to EXIF version 0.73 - while the working one conforms to 0.77. The image sizes reported by 'file' confuse me a bit. In GIMP all these images are 1632 x 1232 pixels.
The stack trace of Dr. Mingw is probably useless, but seems (at least for me) to indicate that the crash happens in libexif: jpeg.exe caused an Access Violation at location 00a6d156 in module libexif-9.dll Reading from location 00aa3001. Registers: eax=00000000 ebx=01281008 ecx=00aa2ffe edx=00aa2ffe esi=0134cd80 edi=00aa2ffa eip=00a6d156 esp=0022f528 ebp=0022f528 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 Call stack: 00A6D156 libexif-9.dll:00A6D156 exif_get_long 00A6188C libexif-9.dll:00A6188C exif_data_new 00A617EB libexif-9.dll:00A617EB exif_data_new 00A617EB libexif-9.dll:00A617EB exif_data_new 00A6220B libexif-9.dll:00A6220B exif_data_load_data 00A62386 libexif-9.dll:00A62386 exif_data_new_from_data 00A6775B libexif-9.dll:00A6775B exif_loader_get_data 00A62534 libexif-9.dll:00A62534 exif_data_new_from_file 0040301F jpeg.exe:0040301F 004019EE jpeg.exe:004019EE 003D3384 libgimp-2.0-0.dll:003D3384 gimp_attach_new_parasite 003D2EE8 libgimp-2.0-0.dll:003D2EE8 gimp_attach_new_parasite 003D1917 libgimp-2.0-0.dll:003D1917 gimp_main 00401315 jpeg.exe:00401315 0040120D jpeg.exe:0040120D 00401238 jpeg.exe:00401238 77E614C7 kernel32.dll:77E614C7 GetCurrentDirectoryW
This looks a lot like a bug in libjpeg or libexif. Here on my linux box GIMP loads the files you attached w/o any problems. Perhaps the problem can be fixed by using newer versions of these libraries. I doubt however that the problem is in the GIMP plug-in. So we can hardly do anything about this.
jpeginfo reports the correct size, btw: after.jpeg: JPEG image data, EXIF standard 0.73 before.jpeg: JPEG image data, EXIF standard 0.77 son.jpeg: JPEG image data, EXIF standard 0.73
How can I get newer versions of these libraries? Are they part of the GTK Toolkit?
libexif is a separate piece of software. I don't know whether Jernej includes it with the GTK+ or GIMP installer, but it isn't properly part of either GTK+ or GIMP. (It's only GIMP's JPEG plug-in that uses it.) The libexif I have built, which presumably is the one Jernej uses, is version 0.5.10. The newest versions seems now to be 0.5.12, so I should provide a build of that instead. Stay tuned.
Nope, just using libexif 0.5.12 doesn't help. Test-tree from libexif 0.5.12 (using a libexif 0.5.12) also crashes on that second cat photo. Will take this up with the libexif author. What libexif version do you use on Linux? Why this images works fine on Linux is unknown. It might be that the libexif library has some odd platform dependency that shows up on Windows just for some images. But the code looks quite clean, and I build it with gcc on Windows, too, so that sounds a bit improbable.
I use libexif-0.5.12 on GNU/Linux.
Same version here (http://packages.debian.org/unstable/libs/libexif9).
After.jpg is indeed damaged. The crash has been already fixed in libexif. The fix consists of these two lines: /* Check if we have enough data. */ if (offset + 12 * n > ds) n = (ds - offset) / 12; in exif_data_load_data_content() in libexif/libexif/exif-data.c. The current libexif available at CVS is not binary compatible with 0.5.12 therefore you have to wait till the jpeg plugin of gimp is upgraded. I used the GIMP source available at the URL in the original bug report (see above), libexif 0.5.12 used by GIMP and the current libexif (to be 0.7.0 pretty soon) from CVS at sf.net. -- Jan Patera, a libexif developer
OK, so the bug is in libexif. Thanks a lot for the feedback. Closing this report as NOTGNOME.