GNOME Bugzilla – Bug 629442
f-spot crashes when trying to import from a direcotry that contains CRW images
Last modified: 2018-07-01 08:50:31 UTC
just tried to import from a directory that contained CRW images (raw images from a canon s40) and f-spot crashed. Removed the CRW images and import worked fine. Perhaps this is related to: Bug 587824? version: git d2a931a9ba19a9c07c729e98967d7cce258706ee on opensuse 11.3 >uname -a Linux linux-ipxf 2.6.34.4-0.1-default #1 SMP 2010-08-20 19:21:29 +0200 i686 athlon i386 GNU/Linux HTH Arun
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Hi installed a bunch of debuginfo packages and run "f-spot --gdb" and then used "thread apply all bt". gdb then seems to hang at Thread 1?! Seems like I'm doing something wrong? Do I need to build f-spot with debug enabled (if so how)? Anyway, here is the output, hope it helps: Starting program: /usr/bin/mono /usr/local/lib/f-spot/f-spot.exe --gdb [Thread debugging using libthread_db enabled] warning: the debug information found in "/usr/lib/debug//lib/libc-2.11.2.so.debug" does not match "/lib/libc.so.6" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/lib/libc-2.11.2.so.debug" does not match "/lib/libc.so.6" (CRC mismatch). Missing separate debuginfo for /lib/libc.so.6 Try: zypper install -C "debuginfo(build-id)=f71a3d8772eda244959bac3385b43c719b8ca227" [New Thread 0xb7b6cb70 (LWP 14206)] [New Thread 0xb6b0eb70 (LWP 14207)] [New Thread 0xb6ae9b70 (LWP 14208)] Missing separate debuginfo for /usr/lib/libfreetype.so.6 Try: zypper install -C "debuginfo(build-id)=b03ecf9218ee146f3f20d792ba1aeb11579570a8" [Info 19:35:12.147] Initializing Mono.Addins [New Thread 0xad924b70 (LWP 14209)] [New Thread 0xad74bb70 (LWP 14210)] [Thread 0xad74bb70 (LWP 14210) exited] [New Thread 0xabaffb70 (LWP 14211)] [New Thread 0xab9feb70 (LWP 14212)] [Thread 0xabaffb70 (LWP 14211) exited] [New Thread 0xabaffb70 (LWP 14213)] [New Thread 0xab75eb70 (LWP 14214)] [New Thread 0xab65db70 (LWP 14215)] [Thread 0xabaffb70 (LWP 14213) exited] [New Thread 0xabaffb70 (LWP 14216)] [Thread 0xab75eb70 (LWP 14214) exited] [New Thread 0xab75eb70 (LWP 14217)] Missing separate debuginfo for /usr/lib/gio/modules/libgiofam.so Try: zypper install -C "debuginfo(build-id)=40b95e5b623deca5896256aeea6dc49d585e7c25" [New Thread 0xad74bb70 (LWP 14218)] [New Thread 0xaa5ffb70 (LWP 14219)] [New Thread 0xa9dfeb70 (LWP 14220)] [Thread 0xa9dfeb70 (LWP 14220) exited] [Thread 0xaa5ffb70 (LWP 14219) exited] [New Thread 0xaa5ffb70 (LWP 14221)] [New Thread 0xa9dfeb70 (LWP 14222)] [Thread 0xaa5ffb70 (LWP 14221) exited] [Thread 0xa9dfeb70 (LWP 14222) exited] [New Thread 0xa95fdb70 (LWP 14223)] [New Thread 0xa9dfeb70 (LWP 14224)] [Thread 0xa95fdb70 (LWP 14223) exited] Program received signal SIGSEGV, Segmentation fault. 0xab5379f6 in ?? () (gdb) thread apply all bt
+ Trace 223679
Thread 13 (Thread 0xab75eb70 (LWP 14217))
Thread 12 (Thread 0xabaffb70 (LWP 14216))
Thread 11 (Thread 0xab65db70 (LWP 14215))
Thread 8 (Thread 0xab9feb70 (LWP 14212))
Thread 5 (Thread 0xad924b70 (LWP 14209))
Thread 1 (Thread 0xb7cc96f0 (LWP 14203)):
This is because Taglib# currently does not handle CRW files yet. See bug 622110.
(In reply to comment #3) > This is because Taglib# currently does not handle CRW files yet. See bug > 622110. But it still looks like a bug in f-spot if a TagLib# functions throwing an UnsupportedFormatException causes f-spot to crash. ;-) It seems that the call to TagLib.File.Create in src/Core/FSpot.Utils/FSpot.Utils/Metadata.cs is actually in a try/catch block, but it looks like that it doesn't work...
Ruben, I think I have tracked down at least one issue: The problem is actually not the exception in TagLib#, but an infinite loop in Ciff.cs: GdkImageLoader.Load calls: image_file.PixbufStream, in our case CiffFile.PixbufStream CiffFile.PixbufStream calls CiffFile.GetEmbeddedJpeg CiffFile.GetEmbeddedJpeg calls Root.ReadEntry which calls the get method of Root CiffFile.Root.get uses lazy initialisation for the "root" member - if it is still null, then the function calls PixbufStream PixbufStream calls then again GetEmbeddedJpeg etc. etc. So finally the program will crash due to a stack overflow cause by the described infinite loop. Probably something like the following patch can solve the issue: diff --git a/src/Clients/MainApp/FSpot.Imaging/Ciff.cs b/src/Clients/MainApp/FSpot.Imaging/Ciff.cs index e5a503d..80b5a35 100644 --- a/src/Clients/MainApp/FSpot.Imaging/Ciff.cs +++ b/src/Clients/MainApp/FSpot.Imaging/Ciff.cs @@ -147,7 +147,7 @@ namespace FSpot.Imaging.Ciff { ImageDirectory Root { get { if (root == null) { - stream = PixbufStream (); + stream = base.PixbufStream (); root = Load (stream); } Although the patch fixes a real bug, that's not enough to fix the issue with the crw file since the remaining source of f-spot is not really prepared that "Metadata.Parse()" may return null (which is the case when TagLib# does not recognize the format).
Created attachment 176699 [details] [review] Change CRW loading as suggested by Christian Krause.
Comment on attachment 176699 [details] [review] Change CRW loading as suggested by Christian Krause. Attachment 176699 [details] pushed as e1bba71 - Change CRW loading as suggested by Christian Krause.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.