GNOME Bugzilla – Bug 466044
JPEG plug-in crashes while opening image with Olympus MakerNote (bug in libexif)
Last modified: 2008-11-11 20:54:00 UTC
Steps to reproduce: 1. open a .jpg file and GIMP crashes the machine by using all memory. 2. reproducible only on certain images, but is consistent with the image 3. Stack trace: N/A Other information: I have several images that cause this behaivior with GIMP. I'm trying other options and also trying a new desktop session, as the one I'm using is from my older 64bit fedora 6 install. I can upload one of the offending files if needed
Yes please, attach the smallest offending file you have.
Is there a place I can upload the file to.. It's 3.7 Mb and is the only image I would want to submit for testing at this time. I tried to upload the image to a free hosting site, but, they modified the image.
Use the link "Create a New Attachment" just below the comment box. It is very likely that the crash is due to an old bug in libexif that has been fixed some time ago, but please attach the image anyway so that we can be sure.
I get the message below when I try to upload it. I tried to compress it but no luck. I can't seem to find a place that will accept this size file. File Too Large The file you are trying to attach is 3768 kilobytes (KB) in size. Non-patch attachments cannot be more than1000 KB. We recommend that you store your attachment elsewhere on the web, and then insert a link to it in a comment, or in the URL field for this bug. Alternately, if your attachment is an image, you could convert it to a compressible format like JPG or PNG and try again.
I have never tried http://bayimg.com/ myself, but they seem to have a generous file size limit, so you could try to upload your image there.
That worked... I hope the image is not altered so the error does not crop up. I'll try downloading the image and see if it is still re-producible. here is the Image: http://bayimg.com/lAfpfaABi
As suspected, the error goes away from the image I downloaded. Gimp still has a problem with the original.
Have you tried to update libexif as you have been told in comment #3?
Robert, if you have no other solution, you can just e-mail the image to me so that I can have a look and decide if this is the old libexif bug or not. Don't use my gimp.org address, but instead send it to raphael(dot)quinet(at)gmail(dot)com.
Raphael, I sent the image and you should have access to it soon. Sven, I'm currently running libexif-0.6.15-2.fc7. Is there a newer version that I don't know about? Thanks, Robert
Alas, I can confirm this bug even when using the latest version of libexif (version 0.6.16). I can also confirm that it is a new bug, different from bug #358117 and its many duplicates. Like several of the previous bugs, this one may also be related to the way libexif parses the Olympus MakerNotes. I am currently investigating this in order to confirm that it is a bug in libexif and not in the way we pass data to it, but it is already clear that the insane amounts of memory are allocated from within libexif. Here is the stack trace that I got when I interrupted the plug-in (at that point, my machine was almost unusable):
+ Trace 155092
In case anyone wants to analyze that image, I have stored it temporarily at: http://wilber.gimp.org/~raphael/P4060241.JPG But I will not keep it there for a long time because the disk is almost full.
A deeper analysis shows that it is definitely a new bug in libexif. It affects all GIMP versions that link with libexif. This bug occurs in the part of libexif that rewrites the Olympus MakerNote. Other programs such as eog (Eye Of Gnome) may not be affected because they do not use the parts of libexif that modify the EXIF block like GIMP does. I traced the way libexif allocates and reallocates memory and I saw that it reallocates a block of memory with small increments until it does this: realloc 0x80a0b58 to size 588 realloc 0x80a0b58 to size 608 realloc 0x80a0b58 to size 616 realloc 0x80a0b58 to size 624 realloc 0x80a0b58 to size 632 realloc 0x80a0dd8 to size 736494126 <-- oops! realloc 0x80a0b58 to size 736494758 This is what kills the system because it reallocates these 700 MB multiple times with increasing sizes, causing huge amounts of data to be copied back and forth in memory. I then added some code to abort the program at the first attempt to allocate insane amounts of memory and I got this stack trace:
+ Trace 155131
In exif_mnote_data_olympus_save() (frame #4), the variable "s" that defines the size increment for the buffer gets the ridiculous value 736481084 when i=862. I have submitted this bug to the libexif maintainers: https://sourceforge.net/tracker/index.php?func=detail&aid=1773810&group_id=12272&atid=112272 This GIMP bug report will remain open until the bug is fixed in libexif.
This also happens to several programs that must also use libexif, gthumb (when saving the image). BTW, this is not only a problem with Olympus images, this also occurs with my Cannon images as well.
If this also happens with Canon images, then please send me a file that triggers this bug (same e-mail address as before). This bug is specific to the Olympus MakerNote, so the crash is probably different with files from a Canon camera. Do these images come straight out of the memory card of the camera, or did you use some program (third-party or supplied with the camera) to download them? Did you use any other program to manipulate these files?
I'm sorry, the other images in question were created with my Olympus as well. These images were all pulled off of the memory card. No third-party applications were used to manipulate these images.
Robert, what Olympus model do you have? Could you please send me a sample image to patera at users.sourceforge.net? Thank you. This bug occurs only when the central IFD is in Big Endian order (I have seen just one file like this) and makernote is also in Big Endian (I have never seen such a file...). (In reply to comment #15) > I'm sorry, the other images in question were created with my Olympus as well. > These images were all pulled off of the memory card. No third-party > applications were used to manipulate these images.
Jan, I sent the image to you, just so other have the info I sent you. I have an Olympus E-20, here is some of the image information about the camera Image Type: jpeg (The JPEG image format) Width: 2560 pixels Height: 1920 pixels Camera Brand: OLYMPUS OPTICAL CO.,LTD Camera Model: E-20,E-20N,E-20P Date Taken: 2002:04:06 05:02:39 Exposure Time: 1/159 sec. Exposure Program: Normal program Metering Mode: Pattern Flash Fired: Flash did not fire. Focal Length: 17.0 mm ISO Speed Rating: 80 Software: 29-1102 Let me know if you have any questions. Thanks, Robert Chapman
Robert, unfortunately I didn't get any email from you and I have no idea what your email address is therefore I have to use this public forum. Anyway, I was able to get some images taken by the same camera from a different source and I was able to reproduce the bug with libexif 0.6.16. (In reply to comment #17) > Jan, I sent the image to you, just so other have the info I sent you.
This bug was probably introduced in libexif 0.6.16 when fixing libexif bug No. 1525770. In that bug, there was a file with big endian main Exif IFD but with little endian makernote. Now from 2 sources I see that there also exist images (taken by Olympus E20) that have both main IFD and makernote IFD in big endian order. Majority of Olympus files is in little endian entirely. The fix for 1525770 did not work correctly with E20 images. I added a really heuristical fix to detect this new case. In libexif CVS since yesterday. Same bug as libexif bug No. 1774626 and 1773810: http://sourceforge.net/tracker/index.php?func=detail&aid=1773810&group_id=12272&atid=112272 http://sourceforge.net/tracker/index.php?func=detail&aid=1774626&group_id=12272&atid=112272
I just tried building libexif from CVS and indeed it seems to fix the problem. Thanks for the quick patch, Jan! We should close this bug report as soon as a new official release of libexif is out. I hope that it will happen before GIMP 2.4 is out, so that we can still bump the required version number in our 'configure' tests.
Yes, I as well patched the fedora source rpm from the CVS and the new build worked fine. This also fixed an issue with another olympus image I had, where it would segfault the gnome plugin while loading. Thanks Jan, Robert
I seem to be getting this exact same thing with images from my Canon D30. Using Gimp 2.2.17 on Windows 2000 Pro. As soon as I attempt opening a .jpg file uploaded from my camera, I get a message about plugin: jpeg.exe crashing. I have a copy of Gimp 2.2.12 around and tried installing it to see what kind of difference it made. With .12, Gimp crashes with "Unknown file type" if I tell Canon's Zoom Browser to open the selected image for editing with an external application choosing Gimp. However, if I already have Gimp up and running, I seem to be able to open the same file satisfactorily.
The exact same thing, including the endianess in the Makernote?
No. This bug is about Olympus makernotes, this Jim's case is about Canon D30 (note: not 30D) - it is different code. Jim has sent me his image and it is entirely in little endian. I do not have gimp. But I am not able to reproduce any problem (testing on Windows) with several libexif versions. I'll follow up with Jim directly and post resume here. > The exact same thing, including the endianess in the Makernote?
Jim, you are probably affected by an older problem, such as bug #358117 or some of its duplicates. GIMP 2.2.12 is more than one year old and was linked with an even older version of libexif. I recommend that you upgrade to GIMP 2.2.17 now, or GIMP 2.4 as soon as it is released. You can also send me the image that causes problems and I will check if the current GIMP can load it or not (see comment #9 for the e-mail address to use). Let's keep this bug report focused on the Olympus MakerNote only.
Err... forget the part of my comment about upgrading to 2.2.17, since you already have that. But you should still upgrade to 2.4 as soon as it is released.
*** Bug 474024 has been marked as a duplicate of this bug. ***
Still no libexif release with this fix...
I know... I'm having a look on the libexif page every few days, hoping that Jan would make a new official release...
I am not doing any releases - I don't have the knowledge needed... That's other guys who make them. Anyway, I asked Raphael (via private mail) few weeks ago when is next GIMP due to know how much time we have. Still waiting for any date... So, how urgent is it?
Hm... given comments #28 and #29, I'd say that it's rather like we're waiting for a new libexif release :)
*** Bug 486620 has been marked as a duplicate of this bug. ***
*** Bug 496067 has been marked as a duplicate of this bug. ***
This is ridiculous. Even though the problem has been fixed in libexif about nine months ago, there is still no libexif release that contains this fix. I just checked and the version that is in debian unstable is still affected by this bug. libexif 0.6.16 still seems to be the latest upstream release.
I tried several months ago to have the libexif patch added into the fedora release (8) and it didn't make it in. I havn't checked, but I think fedora 9 will still have the same issue. I issued a redhat bug that pointed to this error, but I have had no feedback as to the progress of updating libexif in fedora 9 I'm currently running fedora 7 and 8, I had to patch my systems and since then have not had any issues with Olympus images in libexif.
*** Bug 531564 has been marked as a duplicate of this bug. ***
*** Bug 555616 has been marked as a duplicate of this bug. ***
libexif 0.6.17 has finally been released. When we are approaching the next release, we should start to depend on it.
Closing as NOTGNOME then.