| Summary: | crash when synchronising album | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Daniel Bauer <linux> |
| Component: | Metadata-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | caulier.gilles, marcel.wiesweg |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.3.0 | |
| Sentry Crash Report: | |||
|
Description
Daniel Bauer
2007-07-19 11:57:08 UTC
Looks similar to my problems ...
I recently upgraded to KDE3.5.7 from SuSE's rpms (including digikam to 0.9.2-10.1). Tried to fire up digikam this morning but it crashed during startup.Starting from a shell it loads about 18% of the album and then gives me a
Sun Jul 22 06:21:51 Central: digikam
terminate called after throwing an instance of 'Exiv2::Error'
what(): Failed to read image data
KCrash: Application 'digikam' crashing...
libexiv2 has version 0.14-2.1 which to me looks like the recommended version.
KDE-Crashmanager gives me
Using host libthread_db library "/lib/tls/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread 1110733984 (LWP 9894)]
[KCrash handler]
#6 0xffffe410 in __kernel_vsyscall ()
#7 0x414f3541 in raise () from /lib/tls/libc.so.6
#8 0x414f4dbb in abort () from /lib/tls/libc.so.6
#9 0x414a24f1 in __gnu_cxx::__verbose_terminate_handler ()
from /usr/lib/libstdc++.so.6
#10 0x4149fe15 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#11 0x4149fe52 in std::terminate () from /usr/lib/libstdc++.so.6
#12 0x4149ffba in __cxa_throw () from /usr/lib/libstdc++.so.6
#13 0x4201c5b9 in Exiv2::PngChunk::decode () from /usr/lib/libexiv2.so.0
#14 0x4201ba88 in Exiv2::PngImage::readMetadata () from /usr/lib/libexiv2.so.0
#15 0x403b1422 in KExiv2Iface::KExiv2::load ()
from /opt/kde3/lib/libkexiv2.so.1
#16 0x40227d4c in Digikam::DMetadata::load ()
from /opt/kde3/lib/libdigikam.so.0
#17 0x40227dcc in Digikam::DMetadata::DMetadata ()
from /opt/kde3/lib/libdigikam.so.0
#18 0x40159588 in Digikam::ScanLib::storeItemInDatabase ()
from /opt/kde3/lib/libdigikam.so.0
#19 0x4015a06f in Digikam::ScanLib::allFiles ()
from /opt/kde3/lib/libdigikam.so.0
#20 0x4015a549 in Digikam::ScanLib::findMissingItems ()
from /opt/kde3/lib/libdigikam.so.0
#21 0x4015acd7 in Digikam::ScanLib::startScan ()
from /opt/kde3/lib/libdigikam.so.0
#22 0x40114d7f in Digikam::AlbumManager::setLibraryPath ()
from /opt/kde3/lib/libdigikam.so.0
#23 0x0804a8c8 in main ()
Daniel, Hans, Crash appears in Exiv2 library. Please try to use last recent release of Exiv2 library version 0.15. Gilles Caulier Gilles, is it technically possible that digikam is a bit more gentle to the user by not crashing? In particular, it would be helpful if the filename of the problematic file is given in the error message, so that this file could be used to debug the problem? Just my 2 cents, Arnd Arnd, There is 2 problems here: 1/ The first is about to handle properlly C++ exception from Exiv2 when a problem occurs. In current stable implementation of libkexiv2, there is a problem to do it, especially when gcc enable-visiblity option is used to compile library. This problem have been fixed in svn trunk by Marcel recently but not in KDE3 branch : http://websvn.kde.org/?view=rev&revision=693337 Marcel, please backport your patch from trunk to KDE3 branch. Thanks in advance. 2/ The second problem is about the Exiv2 exception. Why it have be generated. Something is wrong in library... With the solution applied to 1/, we will catch the problem and not solve the origin. Gilles Caulier SVN commit 704515 by cgilles: libkexiv2 from KDE3 branch : backport Marcel commit #693337 from trunk (KDE4) about to handle properly Exiv2 exceptions, depending of GCC visility option use to compile. CCBUGS: 148014 --This l from KDEine, and those below, will be ignored-- M kexiv2.cpp M +6 -0 kexiv2.cpp --- branches/extragear/kde3/libs/libkexiv2/libkexiv2/kexiv2.cpp #704514:704515 @@ -51,12 +51,18 @@ // Exiv2 includes. +// The pragmas are required to be able to catch exceptions thrown by libexiv2: +// See http://gcc.gnu.org/wiki/Visibility, the section about c++ exceptions. +// They are needed for all libexiv2 versions that do not care about visibility. +#pragma GCC visibility push(default) +#include <exiv2/error.hpp> #include <exiv2/image.hpp> #include <exiv2/jpgimage.hpp> #include <exiv2/datasets.hpp> #include <exiv2/tags.hpp> #include <exiv2/types.hpp> #include <exiv2/exif.hpp> +#pragma GCC visibility pop // Make sure an EXIV2_TEST_VERSION macro exists: Daniel, Hans, have you tried to use most recent release of Exiv2 library version 0.15? Does the problem persist? Thanks a lot in advance, Arnd According to my (short) test after updating exiv2 with Suse-rpms to 0.15 the crash doesn't happen anymore. (However, it wouldn't write any IPTC to tiff files, but IIRC digikam/tiff/IPTC isn't supportet anyway?) I don't use 0.9.2 anymore usually, but I created two new albums, one with 20 jpgs, another with 20 tiffs. I started 0.9.2 switched off "add Metadata to IPTC" in settings, added a keyword to all images in both albums. Then changed settings again to save Metadata in IPTC, synchronised both albums. All jpg-IPTC were updated. In the tiff-album the job run thru but changed nothing. It also did not crash... >(However, it wouldn't write any IPTC to tiff files, but IIRC digikam/tiff/IPTC isn't supportet anyway?)
Not yet. This is a limitation of Exiv2, not digiKam. Exiv2 0.16 will be released during december and is focalized to XMP support.
Next release (0.17) will certainly support tiff writting mode. Code is under contruction on a dedicaced Exiv2 svn branch...
Gilles Caulier
So this issue seems to be fixed, I am closing the bug (the tiff writing is a different issue). Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4 |