GNOME Bugzilla – Bug 145212
Gimp 2.0 can't open "corrupt" JPG file
Last modified: 2004-07-13 11:21:21 UTC
Gimp 2.0 (windows version (at least)) can't open the jpeg files that my agfa ephoto cl20 ('old' 1M pixel) digital camera takes. It complains with the following messages: 1. Corrupt JPEG data: 250 extraneous bytes before marker 0xd9 2. Gimp Message: Plug-In could not open image 3. Gimp Message: Plug-In crashed "jpeg.exe" 4. (gimp-2.0.exe:2304): LibGimpBase-WARNING **: gimp-2.0.exe: wire_read(): error All my other programs are able to open it .. Firefox/IrfanView/ACDSee. Here is one of those "corrupt" images ... http://individual.utoronto.ca/nezic/tmp/dntest.jpg (temporary) - The problem is reproduceable in linux. - The same error occurs when openning the image with Konqueror (web browser) on KDE. Although, despite the error warning (A message from libjpeg .. "Corrupt JPEG data: 250 extraneous bytes ..."), Konqueror is able to display it.
Created attachment 29123 [details] corrupt jpg sample file
A stack trace shows that the crash is actually occurring in libexif, presumably because there is corrupt EXIF data in the file, or something that looks like EXIF data. I rebuilt Gimp 2.1.1 with --without-libexif, and then Gimp gave the usual error message but loaded the file successfully. This is a rather unfortunate situation, because libexif, while on the whole pretty robust and well-written code, does not seem to be maintained in any formal way at this time. It is hosted on SourceForge -- I left a message in their forum a couple of months ago, asking if anybody was around, and there was no response.
At what point does the plug-in die? If it hasn't created any resources in the core before it crashes then the crash is rather harmless.
Well, the exif part is the last thing that happens. The crash is actually *almost* harmless in another sense -- Gimp does load the image, and you can find it in the Layers dialog, and even copy the layer data by dragging from the Layers dialog, but the image does not get a display. Basically the image is fully created but because of the crash the jpeg plug-in never gets around to returning its ID to the core.
That's rather bad then.
The exif stuff doesn't use anything the plug-in has done earlier -- it works directly from the file name -- so I suppose it would be possible to move it to the beginning of the load_image routine, and cause the crash to occur immediately, if that were desireable.
2004-07-07 Manish Singh <yosh@gimp.org> * plug-ins/common/jpeg.c: Don't try to load EXIF data if any warnings happened, cause that likely means corruption and libexif doesn't handle that very happily. Addresses bug #145212. Perhaps the error and warning messages should be propagated to the user in the GUI somehow, currently they are not.
Leaving open until the error/warning message policy is nailed down, and the fix backported to 2.0.x.
I've changed the error handling so that the warning from libjpeg is shown to the user: 2004-07-13 Sven Neumann <sven@gimp.org> * plug-ins/common/jpeg.c: override the output_message error handler in order to propagate warnings to the user interface (related to bug #145212).
Merged to the stable branch, closing as FIXED. 2004-07-13 Sven Neumann <sven@gimp.org> * plug-ins/common/jpeg.c: merged fix for bug #145212 (JPEG plug-in crashes on corrupt EXIF data) from HEAD branch.