Bug 148014 - crash when synchronising album
Summary: crash when synchronising album
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Engine (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-19 11:57 UTC by Daniel Bauer
Modified: 2021-05-04 10:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bauer 2007-07-19 11:57:08 UTC
Version:           0.9.2 from Suse rpm (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs
OS:                Linux

When synchronising an album with metadata (menu album->Bilder mit Datenbank synchronisieren) in digiKam 0.9.2-final (installed from Suse rpms today) the app crashes.

I have an album with 495 tiff images with tags, that I added using 0.9.1. Tags were only in database, but not in IPTC as per my digikam settings. After installing 0.9.2 I changed settings to add tags to image metadata and then clicked the synchronize menu item. digKam immediately crashed.

I started it again, tried again, crashed again. In the first 5 images the tags have been written to IPTC.

KDE crashmanager gives the following:

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 1110656672 (LWP 10043)]
[KCrash handler]
#6  0xffffe410 in __kernel_vsyscall ()
#7  0x414e5541 in raise () from /lib/tls/libc.so.6
#8  0x414e6dbb in abort () from /lib/tls/libc.so.6
#9  0x414944f1 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#10 0x41491e15 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#11 0x41491e52 in std::terminate () from /usr/lib/libstdc++.so.6
#12 0x41491fba in __cxa_throw () from /usr/lib/libstdc++.so.6
#13 0x4201bd7a in Exiv2::TiffImage::setExifData () from /usr/lib/libexiv2.so.0
#14 0x403b1a2a in KExiv2Iface::KExiv2::save ()
   from /opt/kde3/lib/libkexiv2.so.1
#15 0x403b1c24 in KExiv2Iface::KExiv2::applyChanges ()
   from /opt/kde3/lib/libkexiv2.so.1
#16 0x400d0ee6 in Digikam::MetadataHub::write ()
   from /opt/kde3/lib/libdigikam.so.0
#17 0x4029451f in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#18 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#19 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#20 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#21 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#22 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#23 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#24 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#25 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#26 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#27 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#28 0x4029465d in Digikam::BatchSyncMetadata::parsePicture ()
   from /opt/kde3/lib/libdigikam.so.0
#29 0x40294721 in Digikam::BatchSyncMetadata::parseList ()
   from /opt/kde3/lib/libdigikam.so.0
#30 0x40294767 in Digikam::BatchSyncMetadata::slotAlbumParsed ()
   from /opt/kde3/lib/libdigikam.so.0
#31 0x40294812 in Digikam::BatchSyncMetadata::qt_invoke ()
   from /opt/kde3/lib/libdigikam.so.0
#32 0x40ec13d9 in QObject::activate_signal ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#33 0x40292562 in Digikam::ImageInfoJob::signalItemsInfo ()
   from /opt/kde3/lib/libdigikam.so.0
#34 0x40292f1d in Digikam::ImageInfoJob::slotData ()
   from /opt/kde3/lib/libdigikam.so.0
#35 0x40293051 in Digikam::ImageInfoJob::qt_invoke ()
   from /opt/kde3/lib/libdigikam.so.0
#36 0x40ec13d9 in QObject::activate_signal ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#37 0x40500d0f in KIO::TransferJob::data () from /opt/kde3/lib/libkio.so.4
#38 0x40500d88 in KIO::TransferJob::slotData () from /opt/kde3/lib/libkio.so.4
#39 0x405558f9 in KIO::TransferJob::qt_invoke () from /opt/kde3/lib/libkio.so.4
#40 0x40ec13d9 in QObject::activate_signal ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#41 0x404fdf12 in KIO::SlaveInterface::data () from /opt/kde3/lib/libkio.so.4
#42 0x4056e530 in KIO::SlaveInterface::dispatch ()
   from /opt/kde3/lib/libkio.so.4
#43 0x40512697 in KIO::SlaveInterface::dispatch ()
   from /opt/kde3/lib/libkio.so.4
#44 0x4051759b in KIO::Slave::gotInput () from /opt/kde3/lib/libkio.so.4
#45 0x4051774b in KIO::Slave::qt_invoke () from /opt/kde3/lib/libkio.so.4
#46 0x40ec13d9 in QObject::activate_signal ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#47 0x40ec19c1 in QObject::activate_signal ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#48 0x41211430 in QSocketNotifier::activated ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#49 0x40ee0800 in QSocketNotifier::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#50 0x40e60131 in QApplication::internalNotify ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#51 0x40e60ab9 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#52 0x40b94fae in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#53 0x40e53a0d in QEventLoop::activateSocketNotifiers ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#54 0x40e0cb22 in QEventLoop::processEvents ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#55 0x40e77168 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#56 0x40e77066 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#57 0x40e5fa7f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#58 0x0804aab1 in main ()
Comment 1 Hans Muecke 2007-07-22 13:28:06 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 ()



Comment 2 caulier.gilles 2007-07-22 13:41:39 UTC
Daniel, Hans,

Crash appears in Exiv2 library.

Please try to use last recent release of Exiv2 library version 0.15. 

Gilles Caulier
Comment 3 Arnd Baecker 2007-07-22 14:43:24 UTC
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
Comment 4 caulier.gilles 2007-08-24 22:26:15 UTC
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
Comment 5 caulier.gilles 2007-08-25 10:03:13 UTC
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:
 
Comment 6 Arnd Baecker 2007-11-05 10:28:45 UTC
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
Comment 7 Daniel Bauer 2007-11-05 11:26:07 UTC
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...
Comment 8 caulier.gilles 2007-11-05 11:52:17 UTC
>(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
Comment 9 Arnd Baecker 2007-11-27 08:19:30 UTC
So this issue seems to be fixed, I am closing the bug
(the tiff writing is a different issue).

Comment 10 caulier.gilles 2021-05-04 10:16:46 UTC
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4