after naming faces on some different pictures the main surface freezes Reproducible: Always Steps to Reproduce: 1. open an album 2. open first picture 3. name a face 4. go to next picture, name a face 5. ... n. after several times the surface freezes no chance to choose an other picture or an other album hitting the cloese - x (upper right corner) takes some time before a message box pops up : digikam does not react process 12345 and you can choose button: Prozess digikam beenden? (to end digikam process?) Actual Results: after surface is frozen only killing the process of digikam is working after this I started digikam without gdb from command line and get a lot of error messages
Created attachment 92614 [details] output of gdb start sorry, I'm not able to get the debug symbols in place
Created attachment 92615 [details] start of digikam from command line output when starting digikam without gdb from command line and than getting a lot of error messages
It crash in Exiv2 shared library. Please report this problem including backtraces to Exiv2 bugzilla and possible relevant image files causing problem : http://dev.exiv2.org/projects/exiv2/issues Gilles Caulier
http://dev.exiv2.org/issues/1082 Am 15.05.2015 um 14:44 schrieb Gilles Caulier: > https://bugs.kde.org/show_bug.cgi?id=347753 > > Gilles Caulier <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > CC| |caulier.gilles@gmail.com > Component|Albums GUI |libkexiv2 > Resolution|--- |UPSTREAM > > --- Comment #3 from Gilles Caulier <caulier.gilles@gmail.com> --- > It crash in Exiv2 shared library. > > Please report this problem including backtraces to Exiv2 bugzilla and possible > relevant image files causing problem : > > http://dev.exiv2.org/projects/exiv2/issues > > Gilles Caulier >
Gilles, please take a look at the discussion on this over at exiv2: http://dev.exiv2.org/issues/1082#note-8 What do you think? Might the use of filenames beginning in "---_" be an issue? Or some strange interaction with acdsee support in 4.10.0? -- digikam(6311)/KEXIV2: Cannot remove Xmp tag using Exiv2 (Error # 35 : No namespace info avaible for XMP prefix 'acdsee' digikam(6311)/KEXIV2: Cannot set Xmp tag string into image using Exiv2 (Error # 35 : No namespace info avaible for XMP prefix 'acdsee' --
Hi Alan, the user must update the libkexiv2 to the version from digiKam 4.10.0. digikam(6311)/KEXIV2: Cannot remove Xmp tag using Exiv2 (Error # 35 : No namespace info avaible for XMP prefix 'acdsee' Maik
Created attachment 92736 [details] here I can give a debug output with gdb. I have only one folder with 6 pictures in it. Only thing I have done was to name one single face in faces:unknown after this digikam crashes silently
Created attachment 92740 [details] this is what is installed what is needed version number and where to get for my openSUSE 13.2?
Alan, The backtrace available in Exiv2 report is clear : (gdb) bt #0 0x00007ffff0f494c0 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #1 0x00007fffee5cea56 in Exiv2::XmpProperties::nsInfo(std::string const&) () from /usr/lib64/libexiv2.so.13 #2 0x00007fffee5ceb30 in Exiv2::XmpProperties::ns(std::string const&) () from /usr/lib64/libexiv2.so.13 #3 0x00007fffee5cf36b in Exiv2::XmpKey::Impl::decomposeKey(std::string const&) () from /usr/lib64/libexiv2.so.13 #4 0x00007fffee5cf735 in Exiv2::XmpKey::XmpKey(std::string const&) () from /usr/lib64/libexiv2.so.13 #5 0x00007ffff639d805 in KExiv2Iface::KExiv2::removeXmpTag(char const*, bool) const () from /usr/lib64/libkexiv2.so.11 #6 0x00007ffff5c88b95 in Digikam::DMetadata::setImageTitles (this=this@entry=0x7fffbea895d0, titles=...) at /usr/src/debug/digikam-4.10.0/core/libs/dmetadata/dmetadata.cpp:607 #7 0x0000000000625a30 in Digikam::MetadataHub::write (this=this@entry=0x7fffbea89640, metadata=..., writeMode=writeMode@entry=Digikam::MetadataHub::FullWrite, settings=...) at /usr/src/debug/digikam-4.10.0/core/app/fileaction/metadatahub.cpp:680 #8 0x0000000000627341 in Digikam::MetadataHub::write (this=this@entry=0x7fffbea89640, filePath=..., writeMode=writeMode@entry=Digikam::MetadataHub::FullWrite, settings=...) at /usr/src/debug/digikam-4.10.0/core/app/fileaction/metadatahub.cpp:762 #9 0x000000000062f943 in Digikam::FileActionMngrFileWorker::writeMetadataToFiles (this=<optimized out>, infos=...) at /usr/src/debug/digikam-4.10.0/core/app/fileaction/fileworkeriface.cpp:94 The crash come from Exiv2. This due because xmp namespace from ACDSee is not know by Exiv2. Why exiv2 crash here ? There is no reason... I'm not sure if it's a C++ exception (even we can see "__cxa_throw ()" in backtrace). Because, i'm sure to have patched in far pass libkexiv2 to catch properly Exiv2 exceptions into libkexiv2 (This is one reason why libkexiv2 exist). The crash is reproducible with Exiv2 CLI tool to try to manipulate ACDSee namespace as well (or a small test program can be written in this way) ? Gilles
Johannes , As Maik said digiKam use libkexiv2 interface to play with Exiv2 API. Last Libkexiv2 code is available in digiKam, but generally, distro use kdegraphics/libs components to link digiKam, because this lib is released officially through KDE. Gilles Caulier
Thank you Gilles I assume this means that exiv2 will crash on any XMP namespace that an application like digikam tries to register internally, like you do with acdsee? In which case, the same should happen with the lr namespace, correct? That is another one that exiv2 < 0.25 did not know about.
Alan, Look in backtrace better : #5 0x00007ffff639d805 in KExiv2Iface::KExiv2::removeXmpTag(char const*, bool) const () from /usr/lib64/libkexiv2.so.11 #6 0x00007ffff5c88b95 in Digikam::DMetadata::setImageTitles (this=this@entry=0x7fffbea895d0, titles=...) at /usr/src/debug/digikam-4.10.0/core/libs/dmetadata/dmetadata.cpp:607 It call this : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dmetadata/dmetadata.cpp#L607 It's clear. It's not the registration of ACDSee namepace which crash Exiv2, but the use of an XMP tags with an unknown namespace... ==> removeXmpTag("Xmp.acdsee.caption"); So, it's very easy to check if Exiv2 CLI tool crash in this situation : just try to remove this XMP tag as well from the image and look what's happen. Gilles
The images that Johannes has do not have any acdsee metadata. A simple test did not crash exiv2 CLI. I first tested on a jpeg that does have acdsee metadata and second on a jpeg that does not have acdsee metadata. $ exiv2 -V exiv2 0.24 001800 (64 bit build) $ exiv2 -M"del Xmp.acdsee.caption" image.with.acdsee.tags.jpg -M option 1: Invalid key `Xmp.acdsee.caption' exiv2: Error parsing -M option arguments $ exiv2 -M"del Xmp.acdsee.caption" image.without.acdsee.tags.jpg -M option 1: Invalid key `Xmp.acdsee.caption' exiv2: Error parsing -M option arguments
==> removeXmpTag("Xmp.acdsee.caption"); This is the first and only time that the code tries to remove a tag of a namespace that is unknown to exiv2. All the other instances of removeXmpTag are of a known namespace.
In original crash i can see : #1 0x00007fffee5cea56 in Exiv2::XmpProperties::nsInfo(std::string const&) () from /usr/lib64/libexiv2.so.13 libexiv2.so.13 ==> is Exiv2 0.24 or a previous release ? This error message : -M option 1: Invalid key `Xmp.acdsee.caption' exiv2: Error parsing -M option arguments ... want mean that a C++ exception is generated by Exiv2 kibrary and catch by Exiv2 CLI tool ? Gilles
Created attachment 92742 [details] output of tests if there is any tag of acdsee as in comment #13 same version of exiv2 and no acdsee tag to see
Alan, Also, look like the code in libkexiv2 method removeXmpTag() is catch by C++ : https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/master/entry/libkexiv2/kexiv2xmp.cpp#L1100 So, typically digiKam must not crash in this kind of situation. Gilles
Alan, Look again the backtrace : (gdb) bt #0 0x00007ffff0f494c0 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #1 0x00007fffee5cea56 in Exiv2::XmpProperties::nsInfo(std::string const&) () from /usr/lib64/libexiv2.so.13 #2 0x00007fffee5ceb30 in Exiv2::XmpProperties::ns(std::string const&) () from /usr/lib64/libexiv2.so.13 #3 0x00007fffee5cf36b in Exiv2::XmpKey::Impl::decomposeKey(std::string const&) () from /usr/lib64/libexiv2.so.13 #4 0x00007fffee5cf735 in Exiv2::XmpKey::XmpKey(std::string const&) () from /usr/lib64/libexiv2.so.13 #5 0x00007ffff639d805 in KExiv2Iface::KExiv2::removeXmpTag(char const*, bool) const () from /usr/lib64/libkexiv2.so.11 It look like Exiv2 debug symbols are not installed. So it's impossible to see exactly where in Exiv2 code the problem appears. I recommend : * to install Exiv2 debug package and try to get a better GDB backtrace. * to catch exception directly in GDB before to run digiKam, as explained at https://www.digikam.org/contrib I suspect that Adobe XMP SDK generate an exception which is not catch by Exiv2 code. The previous test with Exiv2 CLI tool can be not enough. I suspect that CLI interface check XMP tag to manage with M option before to do something in file metadata. Gilles
Great. I'll install all the debugging packages and try to reproduce the issue with digikam 4.10.0 and exiv2 0.24. Until this gets fixed in exiv2, perhaps digikam should not try to remove unregistered XMP tags?
Created attachment 92744 [details] try again gdb with all exiv2 debug packages installed run again with more debug files installed
Created attachment 92765 [details] tarball with test case code + jpeg image Alan, See my test case code. To compile : [gilles@localhost bug347753]$ ls bug347753.cpp bug347753.pro test.jpg [gilles@localhost bug347753]$ qmake [gilles@localhost bug347753]$ make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o bug347753.o bug347753.cpp g++ -Wl,-O1 -o bug347753 bug347753.o -L/usr/lib64 -lexiv2 -lQtGui -L/usr/lib64 -L/usr/lib -lQtCore -lpthread [gilles@localhost bug347753]$ ls bug347753* bug347753.cpp bug347753.o bug347753.pro Makefile test.jpg [gilles@localhost bug347753]$ ldd ./bug347753 |grep exiv2 libexiv2.so.13 => /lib/libexiv2.so.13 (0x00007f47d1231000) [gilles@localhost bug347753]$ ./bug347753 [gilles@localhost bug347753]$ So problem is not reproducible with my test image on my computer. Perhaps Johannes have special metadata in image which perturb Exiv2. Other possibility : perhaps Johannes Exiv2 is compiled WITHOUT XMP support. Mine yes of course : [gilles@localhost bug347753]$ nm /lib/libexiv2.so.13 |grep xmp 00000000002cbffd t _GLOBAL__sub_I_xmp.cpp 00000000002d3d95 t _GLOBAL__sub_I_xmpsidecar.cpp 00000000002cb790 t _ZN12_GLOBAL__N_112xmpArrayTypeERKm 00000000002cb7b1 t _ZN12_GLOBAL__N_118xmpArrayOptionBitsEN5Exiv28XmpValue12XmpArrayTypeE 00000000002cb6f3 t _ZN12_GLOBAL__N_118xmpArrayOptionBitsEN5Exiv28XmpValue9XmpStructE 00000000002cb810 t _ZN12_GLOBAL__N_119xmpFormatOptionBitsEN5Exiv29XmpParser14XmpFormatFlagsE 00000000002cb6c7 t _ZN12_GLOBAL__N_19xmpStructERKm 0000000000641040 b _ZN12_GLOBAL__N_1L10xmpHeadersE 0000000000641080 b _ZN12_GLOBAL__N_1L11xmpTrailersE 00000000006410c0 b _ZN12_GLOBAL__N_1L13xmpTrailerEndE 0000000000613b20 D _ZN5Exiv210xmpAuxInfoE 0000000000612400 D _ZN5Exiv210xmpCrsInfoE 0000000000619400 D _ZN5Exiv210xmpDwCInfoE 00000000006120c0 D _ZN5Exiv210xmpPdfInfoE 0000000000610e80 D _ZN5Exiv210xmpXmpInfoE 0000000000612ec0 D _ZN5Exiv211xmpExifInfoE 0000000000613ba0 D _ZN5Exiv211xmpIptcInfoE 0000000000610d80 D _ZN5Exiv211xmpKipiInfoE 0000000000614340 D _ZN5Exiv211xmpPlusInfoE 0000000000612aa0 D _ZN5Exiv211xmpTiffInfoE 0000000000618cc0 D _ZN5Exiv212xmpAudioInfoE 00000000006260c0 d _ZN5Exiv212xmpPrintInfoE 0000000000615ae0 D _ZN5Exiv212xmpVideoInfoE 0000000000611420 D _ZN5Exiv212xmpXmpBJInfoE 0000000000611580 D _ZN5Exiv212xmpXmpDMInfoE 0000000000611160 D _ZN5Exiv212xmpXmpMMInfoE 0000000000611480 D _ZN5Exiv213xmpXmpTPgInfoE 0000000000610c40 D _ZN5Exiv214xmpDigikamInfoE 0000000000613e00 D _ZN5Exiv214xmpIptcExtInfoE 00000000006155a0 D _ZN5Exiv215xmpMediaProInfoE 0000000000611ea0 D _ZN5Exiv216xmpMicrosoftInfoE 0000000000612160 D _ZN5Exiv216xmpPhotoshopInfoE 0000000000611060 D _ZN5Exiv216xmpXmpRightsInfoE 0000000000615920 D _ZN5Exiv217xmpMWGRegionsInfoE 0000000000615760 D _ZN5Exiv221xmpMicrosoftPhotoInfoE 0000000000615680 D _ZN5Exiv222xmpExpressionMediaInfoE 0000000000615840 D _ZN5Exiv227xmpMicrosoftPhotoRegionInfoE 00000000006157c0 D _ZN5Exiv231xmpMicrosoftPhotoRegionInfoInfoE 00000000001fe58a T _ZN5Exiv25Image7xmpDataEv 00000000001fe59c T _ZN5Exiv25Image9xmpPacketEv 000000000032d430 R _ZN5Exiv28JpegBase6xmpId_E 00000000002bd09e T _ZN5Exiv28XmpValue12xmpArrayTypeENS_6TypeIdE 000000000032cee8 r _ZN5Exiv29ImageTypeL3xmpE 0000000000381bf4 r _ZN5Exiv29ImageTypeL3xmpE 00000000006109c0 D _ZN5Exiv29xmpDcInfoE 0000000000612040 D _ZN5Exiv29xmpLrInfoE 0000000000625ba0 D _ZN5Exiv29xmpNsInfoE 0000000000656c30 B _ZN5Exiv29XmpParser11xmpLockFct_E 00000000001fe9c4 T _ZNK5Exiv25Image7xmpDataEv 00000000001fea04 T _ZNK5Exiv25Image9xmpPacketEv 00000000002bd08c T _ZNK5Exiv28XmpValue12xmpArrayTypeEv 00000000002bd0e6 T _ZNK5Exiv28XmpValue9xmpStructEv [gilles@localhost bug347753]$ Gilles
Gilles, Am 21.05.2015 um 17:17 schrieb Gilles Caulier: > https://bugs.kde.org/show_bug.cgi?id=347753 > > --- Comment #21 from Gilles Caulier <caulier.gilles@gmail.com> --- > Created attachment 92765 [details] > --> https://bugs.kde.org/attachment.cgi?id=92765&action=edit > tarball with test case code + jpeg image > > Alan, > > See my test case code. To compile : > > [gilles@localhost bug347753]$ ls > bug347753.cpp bug347753.pro test.jpg > [gilles@localhost bug347753]$ qmake > [gilles@localhost bug347753]$ make > g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB > -DQT_SHARED -I/usr/lib64/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore > -I/usr/include/QtGui -I/usr/include -I. -I. -o bug347753.o bug347753.cpp > g++ -Wl,-O1 -o bug347753 bug347753.o -L/usr/lib64 -lexiv2 -lQtGui > -L/usr/lib64 -L/usr/lib -lQtCore -lpthread > [gilles@localhost bug347753]$ ls > bug347753* bug347753.cpp bug347753.o bug347753.pro Makefile test.jpg > [gilles@localhost bug347753]$ ldd ./bug347753 |grep exiv2 > libexiv2.so.13 => /lib/libexiv2.so.13 (0x00007f47d1231000) > [gilles@localhost bug347753]$ ./bug347753 > [gilles@localhost bug347753]$ > > So problem is not reproducible with my test image on my computer. > > Perhaps Johannes have special metadata in image which perturb Exiv2. first image had no metadata > > Other possibility : perhaps Johannes Exiv2 is compiled WITHOUT XMP support. how do I find out? As I told before: I'm not a coder and I think actually it is impossible for me to compile digikam on my own. I have to take what openSUSE / KDE is offering to me, sorry I will send you a picture to bug-report later. > Mine yes of course : > > [gilles@localhost bug347753]$ nm /lib/libexiv2.so.13 |grep xmp > 00000000002cbffd t _GLOBAL__sub_I_xmp.cpp > 00000000002d3d95 t _GLOBAL__sub_I_xmpsidecar.cpp > 00000000002cb790 t _ZN12_GLOBAL__N_112xmpArrayTypeERKm > 00000000002cb7b1 t > _ZN12_GLOBAL__N_118xmpArrayOptionBitsEN5Exiv28XmpValue12XmpArrayTypeE > 00000000002cb6f3 t > _ZN12_GLOBAL__N_118xmpArrayOptionBitsEN5Exiv28XmpValue9XmpStructE > 00000000002cb810 t > _ZN12_GLOBAL__N_119xmpFormatOptionBitsEN5Exiv29XmpParser14XmpFormatFlagsE > 00000000002cb6c7 t _ZN12_GLOBAL__N_19xmpStructERKm > 0000000000641040 b _ZN12_GLOBAL__N_1L10xmpHeadersE > 0000000000641080 b _ZN12_GLOBAL__N_1L11xmpTrailersE > 00000000006410c0 b _ZN12_GLOBAL__N_1L13xmpTrailerEndE > 0000000000613b20 D _ZN5Exiv210xmpAuxInfoE > 0000000000612400 D _ZN5Exiv210xmpCrsInfoE > 0000000000619400 D _ZN5Exiv210xmpDwCInfoE > 00000000006120c0 D _ZN5Exiv210xmpPdfInfoE > 0000000000610e80 D _ZN5Exiv210xmpXmpInfoE > 0000000000612ec0 D _ZN5Exiv211xmpExifInfoE > 0000000000613ba0 D _ZN5Exiv211xmpIptcInfoE > 0000000000610d80 D _ZN5Exiv211xmpKipiInfoE > 0000000000614340 D _ZN5Exiv211xmpPlusInfoE > 0000000000612aa0 D _ZN5Exiv211xmpTiffInfoE > 0000000000618cc0 D _ZN5Exiv212xmpAudioInfoE > 00000000006260c0 d _ZN5Exiv212xmpPrintInfoE > 0000000000615ae0 D _ZN5Exiv212xmpVideoInfoE > 0000000000611420 D _ZN5Exiv212xmpXmpBJInfoE > 0000000000611580 D _ZN5Exiv212xmpXmpDMInfoE > 0000000000611160 D _ZN5Exiv212xmpXmpMMInfoE > 0000000000611480 D _ZN5Exiv213xmpXmpTPgInfoE > 0000000000610c40 D _ZN5Exiv214xmpDigikamInfoE > 0000000000613e00 D _ZN5Exiv214xmpIptcExtInfoE > 00000000006155a0 D _ZN5Exiv215xmpMediaProInfoE > 0000000000611ea0 D _ZN5Exiv216xmpMicrosoftInfoE > 0000000000612160 D _ZN5Exiv216xmpPhotoshopInfoE > 0000000000611060 D _ZN5Exiv216xmpXmpRightsInfoE > 0000000000615920 D _ZN5Exiv217xmpMWGRegionsInfoE > 0000000000615760 D _ZN5Exiv221xmpMicrosoftPhotoInfoE > 0000000000615680 D _ZN5Exiv222xmpExpressionMediaInfoE > 0000000000615840 D _ZN5Exiv227xmpMicrosoftPhotoRegionInfoE > 00000000006157c0 D _ZN5Exiv231xmpMicrosoftPhotoRegionInfoInfoE > 00000000001fe58a T _ZN5Exiv25Image7xmpDataEv > 00000000001fe59c T _ZN5Exiv25Image9xmpPacketEv > 000000000032d430 R _ZN5Exiv28JpegBase6xmpId_E > 00000000002bd09e T _ZN5Exiv28XmpValue12xmpArrayTypeENS_6TypeIdE > 000000000032cee8 r _ZN5Exiv29ImageTypeL3xmpE > 0000000000381bf4 r _ZN5Exiv29ImageTypeL3xmpE > 00000000006109c0 D _ZN5Exiv29xmpDcInfoE > 0000000000612040 D _ZN5Exiv29xmpLrInfoE > 0000000000625ba0 D _ZN5Exiv29xmpNsInfoE > 0000000000656c30 B _ZN5Exiv29XmpParser11xmpLockFct_E > 00000000001fe9c4 T _ZNK5Exiv25Image7xmpDataEv > 00000000001fea04 T _ZNK5Exiv25Image9xmpPacketEv > 00000000002bd08c T _ZNK5Exiv28XmpValue12xmpArrayTypeEv > 00000000002bd0e6 T _ZNK5Exiv28XmpValue9xmpStructEv > [gilles@localhost bug347753]$ > > Gilles > Johannes
Johaness, >first image had no metadata This is not a condition to crash (:=))... You don't need to code to continue (:=)))... Do you seen my previous comment with all commands to use in a console to compile my test code ? To check if your exiv2 has xmp part compiled : nm /lib/libexiv2.so.13 |grep xmp ... just adjust path to libexiv2.so.13 file Gilles
Am 21.05.2015 um 17:39 schrieb Gilles Caulier: > https://bugs.kde.org/show_bug.cgi?id=347753 > > --- Comment #23 from Gilles Caulier <caulier.gilles@gmail.com> --- > Johaness, > >> first image had no metadata > > This is not a condition to crash (:=))... > > You don't need to code to continue (:=)))... Do you seen my previous comment > with all commands to use in a console to compile my test code ? umh - for this I have to give away of my limitid space of my HD - but to find out what's the problem I like to do it 127 neue Pakete zu installieren. Gesamtgröße des Downloads: 31,1 MiB. Bereits zwischengespeichert: 0 B Nach der Operation werden zusätzlich 123,7 MiB belegt. Fortfahren? [j/n/? zeigt alle Optionen] (j): > > To check if your exiv2 has xmp part compiled : > > nm /lib/libexiv2.so.13 |grep xmp > > ... just adjust path to libexiv2.so.13 file > johannes@linux-johannes-tecra:~/Downloads/bug347753> ls bug347753.cpp bug347753.pro test.jpg johannes@linux-johannes-tecra:~/Downloads/bug347753> qmake johannes@linux-johannes-tecra:~/Downloads/bug347753> make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o bug347753.o bug347753.cpp g++ -Wl,-O1 -o bug347753 bug347753.o -L/usr/lib64 -lexiv2 -lQtGui -L/usr/lib64 -L/usr/X11R6/lib -lQtCore -lpthread johannes@linux-johannes-tecra:~/Downloads/bug347753> ls bug347753 bug347753.cpp bug347753.o bug347753.pro Makefile test.jpg johannes@linux-johannes-tecra:~/Downloads/bug347753> ldd ./bug347753 |grep exiv2 libexiv2.so.13 => /usr/lib64/libexiv2.so.13 (0x00007f8ab1a0c000) johannes@linux-johannes-tecra:~/Downloads/bug347753> ./bug347753 johannes@linux-johannes-tecra:~/Downloads/bug347753> nm /usr/lib64/libexiv2.so.13 |grep xmp nm: /usr/lib64/libexiv2.so.13: no symbols johannes@linux-johannes-tecra:~/Downloads/bug347753> so it seems no. do want something more to test? > Gilles > Johannes
Created attachment 92767 [details] last gdb output
Created attachment 92768 [details] screenshot
link to picture http://picpaste.de/003458.jpg
*** Bug 344735 has been marked as a duplicate of this bug. ***
Problem is fixed with new 7.0.0-beta1 through this long story from this bug https://bugs.kde.org/show_bug.cgi?id=399923 You can test digiKam 7.0.0-beta1 with bundle available here: https://download.kde.org/unstable/digikam/ Don't hesitate to give us a fresh feedback about his entry. Thanks in advance Gilles Caulier