Digikam crashes at startup due to old buggy exiv2 libs.

English Applications
1

Hi,
I am trying to make sense describing the problem, but clearly somebody should get in touch with Gilles Caulier to get the details of this problem that may be happening to far too many users.
In short, Digikam is crashing since a couple of days when the update 4.11 was available from KDE:EXTRA repo.
If you have this repo enabled and updated your OpenSuSE 13.2_x86-64 system, you will kill your Digikam.

The reason is that libexiv2 is still using EXIV2 version 0.24. This is a very buggy version that has made lots of problems specially with video files. I have read about this issue since long time and it is weird that version 0.25 has not yet been implemented despite it is available. For many users it is common to have video and image files together on the same folders managed by Digikam, but this triggers problems due to the known bugs on Exiv2 libraries V.0.24 and have been fixed by V. 0.25.

After contacting Digikam’s editor (Mr. Caulier) it seems to me that the problem relies on libexiv2-13 rpm that provides libexiv2.so.13 (so exiv2 version 0.24 instead of 0.25). I found on the built service, an available rpm libexiv2-14 that provides libexiv2.so.14 with exiv2 version 0.25. However, after installing it it did no difference. Digikam as well as others applications make no use of libexiv2-14 and request libexiv2-13.

I do not understand the details of this issue since Exiv2 is not installed as a package itself or used by default in Opensuse but instead some specific packages (ca. libexiv2 and libkexiv2) and the installation of EXIV2 package makes no difference. Digikam and other apps are requesting this libexiv2-13 package instead of EXIV2 directly or use the most recent version of libexiv2 available.

In summary this problem is happening in three of my four PCs, due to an auto-update feature. Since a couple of days Digikam, together with other apps, is crashing due to these updates that included Digikam 4.11 together with several KDE updates. The issue seems to be due to the urgent need of updating the posted files in KDE:EXTRA and UPDATE repos in order to get fully implemented Exiv2 0.25 quickly since 0.24 is full of bugs (at least about video files).

As my case I can imagine many other users are experiencing this problem.

I tried to downgrade to Digikam 4.10 (that was working fine prior the update), but it has been removed from KDE:EXTRA repo as well as from other repos, and replaced by 4.11 rpms. Finally I was able to find the 4.10 rpms on ftp://ftp.pbone.net/

I have one old box with Digikam 4.10 running fine and attempted to replicate the same rpms to recover control on the damaged PCs.
The list of packages related to Digikam of the running box is:digikam_4.10.0-42.9
digikam-doc_4.10.0-42.9
libkexiv2-11_14.12.3-16.1 (used by digikam)
libexiv2-13_0.24-4.1.9 (notice this has no “k” - it is a different rpm than libkexiv2 and is used by several kde apps)
libkface_14.12.3-10.1
libkface3_14.12.3-10.1
libkgeomap2_4.10.0-42.9
libkipi11_14.12.3-16.1
kipi-plugins-4.10.0-42.9
kipi-plugins-acquireimage-4.10.0-42.9
kipi-plugins-geolocation-4.10.0-42.9
hugin_2013.0.0-3.1.4
libgphoto2-6_2.5.5.1-1.3
libqt_4.8.6-4.4.1
libopencv2_4 (2.4.9-2.1.9)
(exiv2 is not installed, so the libs are the previous - and installing exiv2 rpm with 0.25 does not make any difference)

However the attempt failed. Digikam 4.10 is crashing at startup just the same way as its updated version 4.11.

Here I post part of the crash information of the box with the replica of the running box (the complete code is too long for the allowed size on the post). The crash code when having Digikam 4.11 installed is the same despite the attempts of installing libexiv2-14 / Exiv2 (v0.25), etc.

 Application: digiKam (digikam), signal: Aborted
 Using host libthread_db library "/lib64/libthread_db.so.1".
 [Current thread is 1 (Thread 0x7fe052aaa880 (LWP 2319))]
 

 Thread 30 (Thread 0x7fe02beb5700 (LWP 2343)):
 [KCrash Handler]
 #5  0x00007fe04b4c9187 in raise () at /lib64/libc.so.6
 #6  0x00007fe04b4ca538 in abort () at /lib64/libc.so.6
 #7  0x00007fe04b506844 in  () at /lib64/libc.so.6
 #8  0x00007fe04b50c0ae in malloc_printerr () at /lib64/libc.so.6
 #9  0x00007fe04b50cdb6 in _int_free () at /lib64/libc.so.6

 #10 0x00007fe03f89ecd1 in  () at /usr/lib64/tls/libnvidia-tls.so.304.125
 #11 0x00007fe04914f197 in Exiv2::RiffVideo::infoTagsHandler() () at /usr/lib64/libexiv2.so.13

 #12 0x00007fe049154025 in Exiv2::RiffVideo::decodeBlock() () at /usr/lib64/libexiv2.so.13
 #13 0x00007fe049153c78 in Exiv2::RiffVideo::tagDecoder(Exiv2::DataBuf&, unsigned long) () at /usr/lib64/libexiv2.so.13
 #14 0x00007fe049154025 in Exiv2::RiffVideo::decodeBlock() () at /usr/lib64/libexiv2.so.13
 #15 0x00007fe049154398 in Exiv2::RiffVideo::readMetadata() () at /usr/lib64/libexiv2.so.13
 #16 0x00007fe050ed51a5 in KExiv2Iface::KExiv2::load(QString const&) const () at /usr/lib64/libkexiv2.so.11
 #17 0x00007fe0507ee3e6 in Digikam::DMetadata::load(QString const&) const () at /usr/lib64/libdigikamcore.so.4.10.0
 #18 0x00007fe05023e66f in Digikam::ImageScanner::loadFromDisk() () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #19 0x00007fe05023e850 in Digikam::ImageScanner::newFile(int) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #20 0x00007fe0501d7056 in Digikam::CollectionScanner::scanNewFile(QFileInfo const&, int) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #21 0x00007fe0501da1df in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #22 0x00007fe0501da097 in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #23 0x00007fe0501da097 in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #24 0x00007fe0501da097 in Digikam::CollectionScanner::scanAlbum(Digikam::CollectionLocation const&, QString const&) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #25 0x00007fe0501daaa3 in Digikam::CollectionScanner::scanAlbumRoot(Digikam::CollectionLocation const&) () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #26 0x00007fe0501db67d in Digikam::CollectionScanner::completeScan() () at /usr/lib64/libdigikamdatabase.so.4.10.0
 #27 0x00000000005e3f2f in  ()
 #28 0x00007fe04c05879f in  () at /usr/lib64/libQtCore.so.4
 #29 0x00007fe0476b7754 in  () at /usr/X11R6/lib64/libGL.so.1
 #30 0x00007fe0494c50a4 in start_thread () at /lib64/libpthread.so.0
 #31 0x00007fe04b57908d in clone () at /lib64/libc.so.6
 

 Thread 29 (Thread 0x7fe02b6b4700 (LWP 2344)):
 #0  0x00007fe043634ae2 in  () at /usr/lib64/libglib-2.0.so.0
 #1  0x00007fe043634cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
 #2  0x00007fe04c1870de in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #3  0x00007fe04c158e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #4  0x00007fe04c159165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #5  0x00007fe04c0560bf in QThread::exec() () at /usr/lib64/libQtCore.so.4
 #6  0x00007fe04c13a783 in  () at /usr/lib64/libQtCore.so.4
 #7  0x00007fe04c05879f in  () at /usr/lib64/libQtCore.so.4
 #8  0x00007fe0476b7754 in  () at /usr/X11R6/lib64/libGL.so.1
 #9  0x00007fe0494c50a4 in start_thread () at /lib64/libpthread.so.0
 #10 0x00007fe04b57908d in clone () at /lib64/libc.so.6

  ...

 Thread 1 (Thread 0x7fe052aaa880 (LWP 2319)):
 #0  0x00007fe0494c905f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
 #1  0x00007fe04c058c86 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib64/libQtCore.so.4
 #2  0x00007fe04c04b912 in  () at /usr/lib64/libQtCore.so.4
 #3  0x00007fe04c04cd75 in QThreadPool::~QThreadPool() () at /usr/lib64/libQtCore.so.4
 #4  0x00007fe04c04cda9 in QThreadPool::~QThreadPool() () at /usr/lib64/libQtCore.so.4
 #5  0x00007fe04c170ae8 in QObjectPrivate::deleteChildren() () at /usr/lib64/libQtCore.so.4
 #6  0x00007fe04c17307f in QObject::~QObject() () at /usr/lib64/libQtCore.so.4
 #7  0x00007fe050859c07 in  () at /usr/lib64/libdigikamcore.so.4.10.0
 #8  0x00007fe04b4cbbf9 in __run_exit_handlers () at /lib64/libc.so.6
 #9  0x00007fe04b4cbc45 in  () at /lib64/libc.so.6
 #10 0x00007fe04cbcefc8 in  () at /usr/lib64/libQtGui.so.4
 #11 0x00007fe04d87f9c0 in KApplication::xioErrhandler(_XDisplay*) () at /usr/lib64/libkdeui.so.5
 #12 0x00007fe049a643be in _XIOError () at /usr/lib64/libX11.so.6
 #13 0x00007fe049a61dbd in _XEventsQueued () at /usr/lib64/libX11.so.6
 #14 0x00007fe049a53deb in XEventsQueued () at /usr/lib64/libX11.so.6
 #15 0x00007fe04cc050ec in  () at /usr/lib64/libQtGui.so.4
 #16 0x00007fe043634661 in g_main_context_check () at /usr/lib64/libglib-2.0.so.0
 #17 0x00007fe043634b7b in  () at /usr/lib64/libglib-2.0.so.0
 #18 0x00007fe043634cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
 #19 0x00007fe04c1870de in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #20 0x00007fe04cc05676 in  () at /usr/lib64/libQtGui.so.4
 #21 0x00007fe04c158e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #22 0x00007fe04c159165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #23 0x00000000005dfcb9 in  ()
 #24 0x000000000052fb17 in  ()
 #25 0x00007fe04c17259e in QObject::event(QEvent*) () at /usr/lib64/libQtCore.so.4
 #26 0x00007fe04cb6876c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4
 #27 0x00007fe04cb6ecad in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4
 #28 0x00007fe04d880e0a in KApplication::notify(QObject*, QEvent*) () at /usr/lib64/libkdeui.so.5
 #29 0x00007fe04c15a2ad in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQtCore.so.4
 #30 0x00007fe04c15d57d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQtCore.so.4
 #31 0x00007fe04c1878fe in  () at /usr/lib64/libQtCore.so.4
 #32 0x00007fe043634a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
 #33 0x00007fe043634c48 in  () at /usr/lib64/libglib-2.0.so.0
 #34 0x00007fe043634cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
 #35 0x00007fe04c1870be in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #36 0x00007fe04cc05676 in  () at /usr/lib64/libQtGui.so.4
 #37 0x00007fe04c158e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #38 0x00007fe04c159165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
 #39 0x00007fe04c15e5b9 in QCoreApplication::exec() () at /usr/lib64/libQtCore.so.4
 #40 0x00000000004a0fd0 in  ()

 #41 0x00007fe04b4b5b05 in __libc_start_main () at /lib64/libc.so.6

 #42 0x00000000004a38cf in _start ()

Many thanks in advance.
gps

2

I thought most of those problems have been fixed/workarounded in libkexiv?

I do not understand the details of this issue since Exiv2 is not installed as a package itself or used by default in Opensuse but instead some specific packages (ca. libexiv2 and libkexiv2) and the installation of EXIV2 package makes no difference. Digikam and other apps are requesting this libexiv2-13 package instead of EXIV2 directly or use the most recent version of libexiv2 available.

Yes, exiv2 0.25 is incompatible with 0.24, the so version has changed. So applications built against 0.24 (libexiv2-13) will always use that, namely libexiv2.so.13, even if you install the newer version (libexiv2-14 with the file libexiv2.so.14).

As you mention yourself actually…

In summary this problem is happening in three of my four PCs, due to an auto-update feature. Since a couple of days Digikam, together with other apps, is crashing due to these updates that included Digikam 4.11 together with several KDE updates. The issue seems to be due to the urgent need of updating the posted files in KDE:EXTRA and UPDATE repos in order to get fully implemented Exiv2 0.25 quickly since 0.24 is full of bugs (at least about video files).

Well, it’s probably not possible to update exiv2 for released versions, as mentioned it is incompatible and you would have to rebuild all applications using it too (which might not even be possible in every case) and release them as update too.
But is this even a problem with the digikam in 13.2/Updates?
AIUI, most crashes happened because of newly added features in later digikam versions.

It should be possible to add exiv2 0.25 to KDE:Extra though, and build KDE:Extra’s digikam against it.
Or rather, as digikam actually uses libkexiv2 only which in turn uses libexiv2, you’d need to build libkexiv2 against the newer exiv2.
libkexiv2 is part of the KDE:Applications repo though.

Btw, Tumbleweed does use exiv2 0.25 (only) already since 2 weeks.

Anyway, things like this should rather be reported on bugzilla:
http://bugzilla.opensuse.org/ (same username/password as here)

Btw, you could try digikam5/libKF5KExiv2 from my repo, that is built against exiv2 0.25… :wink:
http://software.opensuse.org/package/digikam5
My packages are co-installable with the KDE4 versions.

I could of course build the latest KDE4 digikam/libkexiv2 against exiv2 0.25 in that repo as well. I will do so anyway when the KF5 based version is released and added to Factory/Tumbleweed to replace the KDE4 version. For now, libkexiv2 should suffice anyway.

3

I totally agree with you WOLFI323.
This is an issue that should have been fixed by LIBKEXIV long time ago.

libkexiv2 installed from KDE:EXTRA together with Digikam 4.11 is : libkexiv2-11 (14.12.3-16.1), providing libkexiv2.so.11 and requiring in turn the file libexiv2.so.13 (the one with the problematic 0.24 version of libexiv).
There is a more recent version of libkexiv2 (15.04.3-1.1) at the KDE:APPLICATIONS repo, providing libkexiv2.so.11 and it was my biggest hope, but it does too requires in turn the same libexiv2.so.13 file to be present instead of libexiv2.so.14 !!! That seems to be the main issue. Why they keep using libexiv2-13 instead of libexiv2-14 even on the most recent versions of libkexiv2 ? :sarcastic:

I installed this more recent version of libkexiv2, but the result is the same crash because is not using the files provided by libexiv2-14…
The best would be to have in KDE:EXTRA a version of libkexiv2 that indeed uses libexiv2-14 that provides libexiv2.so.14.

I am lost between the forum, no idea I was posting this in the wrong place.
Many thanks
gps

4

I hope you don’t mix up libexiv2 and libkexiv2 here.
I do know that some patches have been added to libkexiv2 to detect a buggy libexiv2 and disabling certain features that cause a crash then.

libkexiv2 installed from KDE:EXTRA together with Digikam 4.11 is : libkexiv2-11 (14.12.3-16.1), providing libkexiv2.so.11 and requiring in turn the file libexiv2.so.13 (the one with the problematic 0.24 version of libexiv).

There is no libkexiv2 in KDE:Extra.

There is a more recent version of libkexiv2 (15.04.3-1.1) at the KDE:APPLICATIONS repo, providing libkexiv2.so.11 and it was my biggest hope, but it does too requires in turn the same libexiv2.so.13 file to be present instead of libexiv2.so.14 !!! That seems to be the main issue. Why they keep using libexiv2-13 instead of libexiv2-14 even on the most recent versions of libkexiv2 ? :sarcastic:

As I said, a libkexiv2 (or any other software) built against libexiv2-13 will always use libkexiv2-13.
And there is no updated libexiv2 in KDE:Applications either, so the libkexiv2 there will be built against the one from the distribution, i.e. libexiv2-13 for 13.2, libexiv2-14 on Tumbleweed.

I installed this more recent version of libkexiv2, but the result is the same crash because is not using the files provided by libexiv2-14…
The best would be to have in KDE:EXTRA a version of libkexiv2 that indeed uses libexiv2-14 that provides libexiv2.so.14.

As I already explained. A libexiv2-14 would need to be added to KDE:Applications to make the libkexiv2 there use it.
But probably not all users that install digikam from KDE:Extra would know this, so it probably would be better to add libkexiv2 and libexiv2-14 to KDE:Extra.

I am lost between the forum, no idea I was posting this in the wrong place.

Well, the KDE maintainers are probably not aware of this problem, and probably won’t read this here either.
Also, things mentioned in a forum might get lost or forgotten.

Problems/bugs in some software should always be reported on Bugzilla. Depending on where the problem lies, it should be the upstream Bugzilla (or whatever bugtracking systems they use) or openSUSE’s (for packaging issues like this one).
That’s what bugtrackers are there for. To manage/track bugs.

5

yes libkexiv2 (15.04.3) is posted in KDE:Applications and libexiv2-14 in Graphics among other repos. As you mention the best would be to have a libkexiv2 built against libexiv2-14 and posted in KDE:Extra since is where recent Digikam versions are posted. I will try posting this in the forum you mention. Thanks a lot.

6

Right, but KDE:Applications is not built against graphics or other repos.
As mentioned, it uses the standard libexiv2 from 13.2 for 13.2.

As you mention the best would be to have a libkexiv2 built against libexiv2-14 and posted in KDE:Extra since is where recent Digikam versions are posted. I will try posting this in the forum you mention. Thanks a lot.

Thanks. That’s the best way to getting this solved for 13.2 too.

You should probably mention this thread though, or any others you had upstream (you mentioned getting in touch with the upstream developer, Gilles Caulier), and provide links.

7

Again you are right. But now I have GREAT NEWS!

Recently members of Digikam forum found that there is a recent update in a user repo that did exactly that, built a libkexiv2 against libexiv2-14 and even posted all the packages related (kipi-plugins, etc) in the same repo. Sound logical isn’t it?
This is what it should have been done in KDE:EXTRA as well as packing Digikam 4.11 requesting to have libexiv2-14 installed instead of libexiv2-13.

For users that cannot wait for this to be done, we have this repo with the job done properly: http://download.opensuse.org/repositories/home:/NicoK:/branches:/KDE:/Extra/openSUSE_13.2/
Add it and update your digikam, libkexiv2-11, libexiv2-14, kipi-plugins etc. Thanks for Remco that found this repo as well a NicoK for doing it right.

I shared this with Digikam’s forum as well as opensuse bugzilla.

8

I fully agree.
But the packager(s) might not have been aware of those problems, that’s why I asked you to file a bug report… :wink:

This is what it should have been done in KDE:EXTRA as well as packing Digikam 4.11 requesting to have libexiv2-14 installed instead of libexiv2-13.

Again, having libexiv2-14 installed will not help at all. That’s what you also wrote in the first place anyway.
You need libkexiv2 built against and using libexiv2-13.
I now, I’m nit-picking now, sorry…

For users that cannot wait for this to be done, we have this repo with the job done properly: http://download.opensuse.org/repositories/home:/NicoK:/branches:/KDE:/Extra/openSUSE_13.2/
Add it and update your digikam, libkexiv2-11, libexiv2-14, kipi-plugins etc. Thanks for Remco that found this repo as well a NicoK for doing it right.

Hm, it actually was NicoK who updated digikam in KDE:Extra.

Anyway, there’s not much about “doing it right” anyway. If you add libkexiv2 and libexiv2-14 to the repo, the libkexiv2 will automatically be built against libexiv2-14.
The user still would have to make sure to install libkexiv2 from KDE:Extra though. So probably the digikam package should be modified to require a libkexiv2-11 version greater than 15.04.0 (or similar), but that would be problematic if there would be a future update for 13.2.

That said, it probably would be acceptable to release libexiv2-14 and a libkexiv2 built against it as update for 13.2. Other applications would not have problems because of that as libexiv2-13 would still be available from the main repo (they just won’t use libexiv2-14 though).
OTOH, this is against openSUSE’s update policy, so the maintenance team would have to grant an exception.

I suppose it wouldn’t be feasible to backport all of libexiv2-14’s fixes to libexiv2-13.

I shared this with Digikam’s forum as well as opensuse bugzilla.

Thanks.