Version: 0.9.3 (using KDE KDE 3.5.7) Installed from: Slackware Packages Compiler: gcc (GCC) 4.1.2 OS: Linux The image I will attach to this report is a broken PNG file generated by a rather old version of Kooka when it run out of memory while scanning some document. When this image is present in a subfolder of the main albums folder, digikam crashes when starting up, producing the following backtrace: (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1256372496 (LWP 4031)] [KCrash handler] #5 0xb745d36e in Exiv2::PngChunk::decode () from /usr/lib/libexiv2.so.0 #6 0xb745c47b in Exiv2::PngImage::readMetadata () from /usr/lib/libexiv2.so.0 #7 0xb74cb9de in KExiv2Iface::KExiv2::load () from /usr/lib/libkexiv2.so.3 #8 0xb7e41ffc in Digikam::DMetadata::load () from /usr/lib/libdigikam.so.0 #9 0xb7e4206c in Digikam::DMetadata::DMetadata () from /usr/lib/libdigikam.so.0 #10 0xb7d1ed28 in Digikam::ScanLib::storeItemInDatabase () from /usr/lib/libdigikam.so.0 #11 0xb7d20ec8 in Digikam::ScanLib::allFiles () from /usr/lib/libdigikam.so.0 #12 0xb7d20e76 in Digikam::ScanLib::allFiles () from /usr/lib/libdigikam.so.0 #13 0xb7d216ef in Digikam::ScanLib::findMissingItems () from /usr/lib/libdigikam.so.0 #14 0xb7d2197d in Digikam::ScanLib::startScan () from /usr/lib/libdigikam.so.0 #15 0xb7cdac87 in Digikam::AlbumManager::setLibraryPath () from /usr/lib/libdigikam.so.0 #16 0x0804ad38 in main () Both the fact that this image can't be opened by kuickshow and the backtrace suggest the problem may lie within some libraries external to digikam. However, digikam certainly shouldn't crash - it should display an error message and just show a placeholder instead of thumbnail for that single image. The GIMP is able to open this image - it displays a warning and then shows the partial image that is available (i.e, the upper part of the image is visible and the missing lower part is all black). Once the invalid image is moved out of the album folder so digikam no longer notices it, digikam can start up normally.
Hmm, my image is 2.7 MB in size and the bug system doesn't allow me to upload files larger than 1 MB. Can I upload the file some place else?
Crash appears in Exiv2, not digiKam. Gilles Caulier
Michał, Can you send the image to me directly: a h u g g e l AT g m x DOT n e t Thanks, Andreas
Thanks for the image. This is Exiv2 bug #537 (http://dev.robotbattle.com/bugs/view.php?id=537), it is fixed in SVN rev. 1362. Andreas
Accordingly with Exiv2 bugzilla : http://dev.robotbattle.com/bugs/view.php?id=537 ... this bug have been fixed by Andreas in current implementation of Exiv2 (future 0.16 release) Gilles
Still I think that Michal's point > However, digikam certainly shouldn't crash - it should display an error message > and just show a placeholder instead of thumbnail for that single image. is valid and important. Digikam should behave better in such a situation. Is this technically possible?
Arnd, The crash is indeep in libexiv2. If something is wrong in Exiv2 implementation, the host crash too. Currently, i think than Andreas as used C++ exception to prevent a crash internally. libkexiv2 take a care about exception and in this case just an error will be reported to host. Andreas, if i'm wrong, please fix me... Gilles
Gilles, Yes, exiv2 throws an exception when it encounters a problem that it can't handle. But in case of a bug, i.e., if something unexpected happens, it may just crash. Some applications show a "bomb-screen" in such situations, which usually says something like "We're sorry the application has encountered a problem and needs to be closed". At least it doesn't just disappear, although the net effect is not so different. I think KDE apps do that. What about digiKam? Do external libraries need to behave in a certain way to enable an application to support this also for crashes of the library? Andreas
Andreas, Well, i have no idea how to make this behaviors in digiKam/libkexiv2 when a crash appears in a shared library... Marcel, are you any ideas about this subject ? Gilles
"Dr.Konqi" appears regardless if the crash appears in a shared library or in the main application - if you look at our binary layout, I would guess that 98% of the code is in shared libraries anyway (from libc over Qt and kdelibs to libdigikam). "Not crashing" is unfortunately not possible. There is no difference from which binary object the crash comes, it is all code that the process executes, which is then killed by the OS. Amarok has gone so far as to source out collection scanning to a dedicated process, which may then crash. This is a solution, but so far I think we do not need it so much because 1) libexiv2 crashes are rare as it appears to me 2) libexiv2 is very well maintained Andreas, don't know if you have heard of this toy: http://sam.zoy.org/zzuf/