GNOME Bugzilla – Bug 382382
Crash on wrong exif date
Last modified: 2009-02-16 07:17:07 UTC
Steps to reproduce: I just installed 0.3.0 yesterday, and while importing some pictures I ran into an out of memory crash. It happened because of an invaild exif date into the file. I've seen bug 330785 which refers to wrong date. But in my case f-spot filled the whole ram/swap and then crashed. Stack trace: Other information:
Created attachment 77684 [details] exiftool of the image
Created attachment 77685 [details] The error at the console
can you also attach a complete image file to reproduce this bug ?
Hi Lorenzo, I received your image by e-mail and though I have this exception: ==snip error parsing 0000:00:00 00:00:00 System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: Parameters describe an unrepresentable DateTime. at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond) [0x00000] ... ==snap this exception is well caught and the image is imported...
i got the problem when importing the whole directory, so maybe I did a wrong analysis. as you can see in the log there are many errors like that, maybe too many wrong dates will cause the out of memory? I will try to better understand, or maybe try to send you the whole directory :) I'll do some more tests and let you know. Thanks maxxer
I tried reproducing with a smaller set of pictures and happened again. With some variations. Maybe the "offending" picture is 102? I will send to you and Larry this set of pictures (6Mb). At first time F-spot imported them, taking VERY long time. I tried importing them again without closing F-spot and at picture 5 it filled my ram (512) and then crashed with the following output. To be right I didn't import them! I just selected the directory and let the preview appear in the import dialog. F-spot crashed there. ==== System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: Parameters describe an unrepresentable DateTime. at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond) [0x00000] at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second) [0x00000] at FSpot.Tiff.DirectoryEntry.DateTimeFromString (System.String dt) [0x00000] at FSpot.Tiff.DirectoryEntry.get_ValueAsDate () [0x00000] at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000] error parsing 0000:00:00 00:00:00 System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: Parameters describe an unrepresentable DateTime. at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond) [0x00000] at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second) [0x00000] at FSpot.Tiff.DirectoryEntry.DateTimeFromString (System.String dt) [0x00000] at FSpot.Tiff.DirectoryEntry.get_ValueAsDate () [0x00000] at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000] open uri = file:///home/maxxer/Photos/2006/12/5/img-102.jpg old = "" new = "" heading = "ASCII" value = 2006:12:05 19:40:05 len = 19 value = f-spot version 0.3.0 len = 20 value = 2006:12:05 19:22:29 len = 19 value = f-spot version 0.3.0 len = 20 value = 2006:12:05 19:22:29 len = 19 ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Stacktrace: at (wrapper managed-to-native) Exif.ExifData.exif_data_save_data (System.Runtime.InteropServices.HandleRef,intptr&,uint&) <0x00012> at (wrapper managed-to-native) Exif.ExifData.exif_data_save_data (System.Runtime.InteropServices.HandleRef,intptr&,uint&) <0xffffffff> at Exif.ExifData.Save () <0x00047> at JpegHeader.SetExif (Exif.ExifData) <0x0002c> at FSpot.JpegFile.SaveMetaData (System.IO.Stream,System.IO.Stream) <0x00061> at FSpot.JpegFile.SaveMetaData (string) <0x0005e> at Photo.WriteMetadataToImage () <0x00194> at MainWindow.HandleDbItemsChanged (object,DbItemEventArgs) <0x0010a> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_object_DbItemEventArgs (object,DbItemEventArgs) <0xffffffff> at DbStore.EmitChanged (DbItem[],DbItemEventArgs) <0x00039> at PhotoStore.Commit (DbItem[],DbItemEventArgs) <0x000c5> at PhotoStore.Commit (DbItem) <0x00060> at FileImportBackend.Step (Photo&,Gdk.Pixbuf&,int&) <0x00725> at ImportCommand.Step () <0x00071> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_bool () <0xffffffff> at FSpot.Delay.HandleOperation () <0x0003a> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_bool () <0xffffffff> at IdleProxy.Handler () <0x00045> at (wrapper native-to-managed) IdleProxy.Handler () <0xffffffff> at (wrapper managed-to-native) Gtk.Dialog.gtk_dialog_run (intptr) <0x0000b> at (wrapper managed-to-native) Gtk.Dialog.gtk_dialog_run (intptr) <0xffffffff> at Gtk.Dialog.Run () <0x00034> at ImportCommand.ImportFromFile (PhotoStore,string) <0x0069d> at MainWindow.HandleImportCommand (object,System.EventArgs) <0x00079> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_object_EventArgs (object,System.EventArgs) <0xffffffff> at GLib.Signal.voidObjectCallback (intptr,intptr) <0x000c9> at (wrapper native-to-managed) GLib.Signal.voidObjectCallback (intptr,intptr) <0xffffffff> at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x0000b> at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff> at Gtk.Application.Run () <0x00008> at Gnome.Program.Run () <0x0000c> at FSpot.Driver.Main (string[]) <0x0084f> at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: f-spot [0x505482] f-spot [0x4d170d] /lib/libpthread.so.0 [0x2b5cc8459f50] /usr/lib/libexif.so.10(exif_set_sshort+0xb) [0x2aaab3638a6b] /usr/lib/libexif.so.10 [0x2aaab3631ef8] /usr/lib/libexif.so.10 [0x2aaab3632238] /usr/lib/libexif.so.10(exif_data_save_data+0xf3) [0x2aaab3632673] [0x429644e5] Abortito
Hi Maxxer, I received your mail with the wedding's pictures. Indeed, I can (almost) reproduce your bug importing the whole directory. When I say 'almost', it means I can see the memory leak in any memory usage tool but hopefully I have any available ram on my system to not ran OutOfMemory. So, yeah, call the plumber, there's a leak ! Since F-Spot is a managed application (and thus garbage collected), my guess is that the leak is either in mono or in one of the libs we P/Invoke.
good! But is that related to the exif data or not? If you remember, some time ago in the list I reported that after a long session (4/6h) of importing and tagging I got my memory filled up. And other people experienced the same! Could be those thing be related? Thanks! maxxer
almost certainly. This appears to be a libexif bug when saving.
*** Bug 330785 has been marked as a duplicate of this bug. ***
*** Bug 406764 has been marked as a duplicate of this bug. ***
*** Bug 391564 has been marked as a duplicate of this bug. ***
*** Bug 435476 has been marked as a duplicate of this bug. ***
*** Bug 430424 has been marked as a duplicate of this bug. ***
*** Bug 442936 has been marked as a duplicate of this bug. ***
Created attachment 89889 [details] exif info about portrait photo with faulty exif thumbnail
I am experiencing similar issues with some photos a friend of mine sent me (memory consumption followed by crash). It is also related to the EXIF data, but not specifically the date and time being zeroed out. Only the portrait photos in the set experience this bug. Landscape photos in the collection have no problems. Further, it appears that it's the EXIF thumbnails that are causing the problems. After running ``jhead -dt'' on a photo, it can be imported without any problems. You can find an original photo at <http://kurtmckee.org/files/gnome-bug-382382.jpeg>
if it is a libexif bug, maybe it should be reported to libexif? don't you think?
(In reply to comment #18) > if it is a libexif bug, maybe it should be reported to libexif? don't you > think? the bug is still in state UNCONFIRMED.
I don't know if it can be useful but... I was tagging pictures WITHOUT the write metadata flag. Memory usage was high but quite stable. As I started editing tags' labels, mem usage started raising to the top! I couldn't precisely reproduce this, but I thought the fact of the unset flag could be meaningful to the bug.
I confirm. Even just browsing pictures within tags icon modification makes memory consumption rising fast! At least on my pc... It also takes long time in loading pictures while browsing. This tag I was modifying had 200+ 4Mb jpg pictures associated.
It's a libexif bug (I've already sent a report to the libexif list). In case anyone has a few cycles to tackle the issue, I've put up testcase + faulty image here: http://michele.pupazzo.org/files/exif-bug.tgz
Bug has been fixed in upstream libexif. I just checked and the fix works for me. For the record the fixed revision is r1.30 of libexif/olympus/exif-mnote-data-olympus.c in libexif's CVS. I'll go ahead and close this. (Hopefully we'll get a new libexif release or the distros will have to pick up the exif fix separately)
I confirm! I recompiled libexif with the patch and F-spot imported the wedding pictures (which were the same of Michele :-P ) without crashing! Now it remains the problem of high memory usage when browsing tag's icon...
*** Bug 482038 has been marked as a duplicate of this bug. ***
*** Bug 571891 has been marked as a duplicate of this bug. ***