GNOME Bugzilla – Bug 474710
eog crashes when you try to open this .jpg file (it works fine on Vista/XP)
Last modified: 2007-09-10 02:58:36 UTC
Steps to reproduce: 1. open the attached .jpg file in EOG 2. sigsegv 3. no profit Stack trace: Other information:
I could not attach the file because it's 2.7MB and bugzilla allows max 1MB for attachments. My shell where I usually publish files seems to be down at the moment.
Here is the stacktrace: [New Thread -1226901840 (LWP 23791)] [New Thread -1228223600 (LWP 23794)] [New Thread -1250952304 (LWP 23795)] /bin/sh: /usr/bin/esd: not found Program received signal SIGSEGV, Segmentation fault.
+ Trace 161215
Thread NaN (LWP 23794)
Could you please send me the image privately?
I managed to upload the image now: http://mnemo.minimum.se/bild_tagen_med_wonks_d200_macro.jpg
Confirming. This can be reproduced with trunk, but not with 2.18. Seems like related with the loader.
Other stacktrace I get: (gdb) back
+ Trace 161241
It looks like corruption somewhere...
It seems this is a regression after Hubert's work on XMP metadata (bug #451101). Revision 3889 doesn't crash with that image, and revision 3890 does. I'm not sure yet why this image triggers this issue. Martin, what's special about this image? Adding Hubert to the CC list.
By the way, running eog with EOG_DEBUG_IMAGE_DATA=1, outputs the following (removing some output for readability): claudio@dijkstra:~/svn/gnome-2.20/eog$ EOG_DEBUG_IMAGE_DATA=1 eog bild_tagen_med_wonks_d200_macro.jpg eog-image.c:427 (check_for_metadata_img_format) Check image format for jpeg: ffd8 - length: 65535 eog-metadata-reader.c:205 (eog_metadata_reader_consume) APPx Marker Found: e1 eog-metadata-reader.c:262 (eog_metadata_reader_consume) Read APP1 data, Length: 65532 eog-metadata-reader.c:319 (eog_metadata_reader_consume) Read continuation of EXIF data, length: 3 eog-metadata-reader.c:319 (eog_metadata_reader_consume) Read continuation of EXIF data, length: -65532 eog-metadata-reader.c:319 (eog_metadata_reader_consume) Read continuation of EXIF data, length: -131067
Concerning what's special with this JPG... it's taken with a Nikon D200 camera and it hasn't been edited in some program yet (it comes directly from the camera). Maybe the D200 has some special EXIF block that triggers the bug?
Created attachment 95179 [details] [review] patch This patch seems to correctly read the exif bunch when it's size is smaller than the buffer read. In the particular case of that image, priv->size == 3, and len == 64kB, so it makes no sense to copy the whole buffer, but only the next three bytes.
I've applied this patch to trunk and it works for me, it also works to open another .jpg taken with the same camera (this image also caused a crash before). I also took a .JPG shoot with my Nikon D50 and that opens just fine with correct EXIF etc.
Created attachment 95183 [details] [review] take the XMP case into consideration (untested with XMP files) I suspect similar issues may arise with the XMP reader. This patch would take care of that. I also think the code should be factored out to a helper function, because it's the same bunch over and over again, only changing the destination chunk and the state.
(In reply to comment #12) >I also think the code should be factored out to a helper > function, because it's the same bunch over and over again, only changing the > destination chunk and the state. I opened bug #474931 with a patch to factor out the code.
The second patch works fine with me including with images I have with XMP. Thanks cluadio.
Claudio, the patch is ok. Go on and commit. Thanks!
Fixed in trunk (rev. 4071). Martin, Hub, Lucas: Thank you all! 2007-09-09 Claudio Saavedra <csaavedra@alumnos.utalca.cl> * src/eog-metadata-reader.c: (eog_metadata_reader_consume): Copy only the remaining bytes of EXIF/XMP data if these are smaller than the buffer that's being consumed. Fixes bug #474710.