After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 493530 - Importing JPG causes 100% CPU usage and HUGE Memory Leak
Importing JPG causes 100% CPU usage and HUGE Memory Leak
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Import
0.4.x
Other All
: Normal critical
: 0.7.2
Assigned To: F-spot maintainers
F-spot maintainers
Depends on: 623869
Blocks:
 
 
Reported: 2007-11-04 22:07 UTC by dustin_mccartney
Modified: 2010-08-07 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Another photo that demonstrates this bug. (144.15 KB, image/jpeg)
2008-04-05 20:21 UTC, Tim Retout
  Details
Test Image to demonstrate bad metadata (432.69 KB, image/jpeg)
2009-03-31 08:30 UTC, Hendrick Musche
  Details
[IFD] Fix parsing with non-null delimited strings. (171.70 KB, patch)
2010-08-07 14:46 UTC, Ruben Vermeersch
committed Details | Review

Description dustin_mccartney 2007-11-04 22:07:38 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.
Comment 1 Maxxer 2007-11-05 07:12:03 UTC
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


Comment 2 Maxxer 2007-11-07 08:33:11 UTC
Can this be the problem?

Exif Byte Order                 : Big-endian (Motorola)
Comment 3 Bengt Thuree 2007-11-21 18:10:13 UTC
Can we create a small patch to avoid this one?
Comment 4 Tim Retout 2008-04-05 20:21:59 UTC
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.
Comment 5 Hendrick Musche 2009-03-31 08:30:17 UTC
Created attachment 131753 [details]
Test Image to demonstrate bad metadata
Comment 6 Hendrick Musche 2009-03-31 08:34:39 UTC
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.
Comment 7 Ruben Vermeersch 2010-05-19 14:37:24 UTC
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#.
Comment 8 Ruben Vermeersch 2010-07-08 18:25:58 UTC
These are files with broken offsets. Need to fix this in Taglib#.
Comment 9 Ruben Vermeersch 2010-08-07 14:46:06 UTC
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 10 Ruben Vermeersch 2010-08-07 14:47:14 UTC
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.