GNOME Bugzilla – Bug 493530
Importing JPG causes 100% CPU usage and HUGE Memory Leak
Last modified: 2010-08-07 14:47:14 UTC
Please describe the problem: Importing some .jpg photos created from the Sony DSC-F717 camera causes CPU usage to spike and stay at 100% as well as all available memory (real and swap) gets used before an error is thrown. The larger the memory and swap file, the longer the system is unusable until all swap space is used. Steps to reproduce: 1. Download to a local folder the .jpg file: http://test.damentertainment.com/other/fstop/error_photo_resized.jpg 2. Open F-Spot and click "Import" toolbar button. 3. Choose the folder where you placed the downloaded .jpg file. Actual results: CPU usage goes to 100% and all available memory gets allocated, making the OS unusable. Expected results: I would expect the file to import like any other photo. Does this happen every time? YES. Other information: Some pictures from the Sony DSC-F717 cause this problem, others work fine. I am including one that causes the problem. Additionally, the error dialog that is eventually thrown is: http://test.damentertainment.com/other/fstop/error_msg.png (in that error message, the photo filename is different... I changed the filename when I uploaded the photo). I tried this "error_photo_resized.jpg" on F-Stop 4.0 on both Ubuntu 7.10 (AMD64) and openSuSE 10.3 (PentiumD) and the problem is the same on both machines.
Confirmed also on the latest SVN. When opening with GQView 2.1.5 says: warning: exif tag unknown data will overrun end of file, ignored. Run from an Ubuntu (f-spot 0.4), stops almost at once saying "Out of memory". This is the console log: item ImportCommand+SourceItem Scanning /home/user/Scrivania item changed open uri = file:///home/user/Scrivania/error_photo_resized.jpg cleanup context System.OutOfMemoryException: Out of memory at <0x00000> <unknown method> at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) at FSpot.Tiff.DirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.LoadEntries (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.Load (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory..ctor (System.IO.Stream stream, UInt32 start_position, Endian endian) [0x00000] at FSpot.Tiff.Header..ctor (System.IO.Stream stream) [0x00000] at JpegHeader.GetExifHeader () [0x00000] at FSpot.JpegFile.get_ExifHeader () [0x00000] at FSpot.JpegFile.get_Date () [0x00000] open uri = file:///home/user/Scrivania/error_photo_resized.jpg System.OutOfMemoryException: Out of memory at <0x00000> <unknown method> at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) at FSpot.Tiff.DirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.LoadEntries (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.Load (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory..ctor (System.IO.Stream stream, UInt32 start_position, Endian endian) [0x00000] at FSpot.Tiff.Header..ctor (System.IO.Stream stream) [0x00000] at JpegHeader.GetExifHeader () [0x00000] at FSpot.JpegFile.get_ExifHeader () [0x00000] at FSpot.JpegFile.get_Date () [0x00000] System.OutOfMemoryException: Out of memory at <0x00000> <unknown method> at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) at FSpot.Tiff.DirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.LoadEntries (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.Load (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory..ctor (System.IO.Stream stream, UInt32 start_position, Endian endian) [0x00000] at FSpot.Tiff.Header..ctor (System.IO.Stream stream) [0x00000] at JpegHeader.GetExifHeader () [0x00000] at FSpot.JpegFile.get_ExifHeader () [0x00000] at FSpot.JpegFile.get_Date () [0x00000] open uri = file:///home/user/Photos/2007/11/05/error_photo_resized.jpg open uri = file:///home/user/Photos/2007/11/05/error_photo_resized.jpg error checking orientation open uri = file:///home/user/Photos/2007/11/05/error_photo_resized.jpg Error importing /home/user/Scrivania/error_photo_resized.jpg System.OutOfMemoryException: Out of memory at <0x00000> <unknown method> at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_array_new_specific (intptr,int) at FSpot.Tiff.DirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.LoadEntries (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory.Load (System.IO.Stream stream) [0x00000] at FSpot.Tiff.ImageDirectory..ctor (System.IO.Stream stream, UInt32 start_position, Endian endian) [0x00000] at FSpot.Tiff.Header..ctor (System.IO.Stream stream) [0x00000] at JpegHeader.GetExifHeader () [0x00000] at FSpot.JpegFile.get_ExifHeader () [0x00000] at FSpot.JpegFile.get_Date () [0x00000] Could not import file Stopping
Can this be the problem? Exif Byte Order : Big-endian (Motorola)
Can we create a small patch to avoid this one?
Created attachment 108689 [details] Another photo that demonstrates this bug. The links in the original report are now broken. This bug was also reported in Debian at http://bugs.debian.org/439192 - this attachment is the photo attached to the Debian bug. At the time, I noted that exif reported both these photos as corrupt: tim@regulus:~$ exif IMG_0836.jpg Corrupt data (ExifData): Bogus offset of IFD1. But there were other tools that worked okay with the metadata.
Created attachment 131753 [details] Test Image to demonstrate bad metadata
Comment on attachment 131753 [details] Test Image to demonstrate bad metadata I still have this issue with 0.5.0.3 on Ubuntu Jaunty Beta, although without the CPU maxing out. All Images taken with my HTC Touch Diamond sem to have some funny EXIF data. "metacam IMAGE_061.JPG" gives an error WARNING: Unknown field type 0 while the exif command doesn't find anything suspect.
Interesting stuff. I suspect this will be fixed with the switch to Taglib#. Adding blocker to make sure we add these images to the regression suite of Taglib#.
These are files with broken offsets. Need to fix this in Taglib#.
Created attachment 167322 [details] [review] [IFD] Fix parsing with non-null delimited strings. There was an interesting off-by-one parsing error for strings that were not delimited by a null byte. This commit makes sure we read the entire byte array and then cut of everything up to the null byte.
Comment on attachment 167322 [details] [review] [IFD] Fix parsing with non-null delimited strings. The given file is corrupt, but also has an interesting use of strings (might be corrupt as well). Taglib# now handles them, but refuses to write these files. Should work without any issue in F-Spot. Attachment 167322 [details] pushed as 9536b84 - [IFD] Fix parsing with non-null delimited strings.