Created attachment 88731 [details] Stack backtrace Reproducible: Always Steps to Reproduce: 1. Start Digikam 2. Select a photo in any album 3. Go to the Captions/tags sidebar 4. Go to the information tab 5. Try using a template (that has worked plenty of times in the not too distant past). Actual Results: CPU utilization of one core goes to 100%. Digikam is unresponsive. This problem occurs when "Apply"ing a title to a photo also. Expected Results: Add the copyright information from the template into the photo metadata. The attachment has a gdb stack backtrace from attaching to a digikam in the infinite loop. Relevant packages installed (from OpenSUSE repositories): $ rpm -qa | egrep -i 'digikam|qt' yast2-control-center-qt-3.0.0-2.1.3.x86_64 qt4-qtscript-0.2.0-8.1.3.x86_64 libQtGStreamer-0_10-0-debuginfo-0.10.3-1.1.x86_64 libQtGStreamer-0_10-0-0.10.3-1.1.x86_64 libntrack-qt4-1-016-7.1.3.x86_64 gstreamer-0_10-plugins-qt-0.10.3-1.1.x86_64 libqt4-sql-4.8.5-5.9.2.x86_64 libqt4-qt3support-32bit-4.8.5-5.9.2.x86_64 texlive-qpxqtx-2013.72.svn15878-11.2.1.noarch libyui-qt5-2.43.5-2.1.4.x86_64 libqt4-sql-mysql-32bit-4.8.5-5.9.2.x86_64 libsvnqt7-1.6.0-5.1.3.x86_64 libqt4-qt3support-4.8.5-5.9.2.x86_64 libmygpo-qt1-1.0.7-2.1.2.x86_64 libpolkit-qt-1-1-0.103.0-2.1.3.x86_64 libQtWebKit4-32bit-4.8.5+2.3.3-2.6.1.x86_64 qt3-3.3.8c-128.1.2.x86_64 libpoppler-qt4-4-0.24.3-12.1.x86_64 python-qt4-devel-4.10.3-3.4.1.x86_64 libQtGLib-2_0-0-0.10.3-1.1.x86_64 libyui-qt-graph5-2.42.7-2.2.1.x86_64 libqt4-x11-32bit-4.8.5-5.9.2.x86_64 libyui-qt-pkg5-2.42.13-2.4.1.x86_64 yast2-qt-branding-openSUSE-13.1-10.4.13.noarch libqt4-sql-32bit-4.8.5-5.9.2.x86_64 libqt4-4.8.5-5.9.2.x86_64 libqt4-sql-mysql-4.8.5-5.9.2.x86_64 digikam-doc-3.5.0-7.3.noarch libpackagekit-qt2-6-0.8.8-2.2.2.x86_64 python-qt4-utils-4.10.3-3.4.1.x86_64 libqt4-sql-sqlite-32bit-4.8.5-5.9.2.x86_64 pinentry-qt4-0.8.3-2.1.3.x86_64 libqt4-devel-4.8.5-5.9.2.x86_64 libqt4-32bit-4.8.5-5.9.2.x86_64 digikam-debuginfo-4.3.0-19.1.x86_64 libQtWebKit4-4.8.5+2.3.3-2.6.1.x86_64 appmenu-qt-0.2.6-6.1.2.x86_64 libqt4-linguist-4.8.5-5.9.2.x86_64 texlive-qpxqtx-doc-2013.72.svn15878-11.2.1.noarch ibus-qt-1.3.2-2.1.2.x86_64 libQtGLib-2_0-0-debuginfo-0.10.3-1.1.x86_64 digikam-4.3.0-19.1.x86_64 libqt4-sql-sqlite-4.8.5-5.9.2.x86_64 python-qt4-4.10.3-3.4.1.x86_64 libdbusmenu-qt2-0.9.2-7.1.3.x86_64 libqt4-x11-4.8.5-5.9.2.x86_64 Problem also exists with libqt4-4.8.5-5.6.1.x86_64 Problem also exists with Digikam 4.2.
There is nothing to see in your backtrace. Showing debug statements in the console will be more informative about operation performed in background. Look how to turn on debug statements in this page at "For hangs out or dysfunctions" section : https://www.digikam.org/contrib Gilles Caulier
Created attachment 88739 [details] Debug statements from Digikam All Info and warnings for Digikam, core, kio-slave, showfoto, editor plugins, and database server.
For the attached info and warnings, the following appeared in my terminal window: $ digikam Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. Killed I killed Digikam after it was in the infinite loop. I can also give you a full backtrace rather than just the first page, if that would be more useful.
After this line : digikam(8733)/digikam (core) Digikam::DNotificationWrapper: Event is dispatched to KDE desktop notifier ... there is nothing. If you try to reproduce the problem (the infinite loop stuff), something must be printed on the console, especially if tags are changed... Sound like you have started digiKam and that all... Did you enable KExiv2 and KDcraw debug spaces ? Gilles Caulier
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. Killed ==> This messages are not the origin of the problem. This just warnings from Qt. 2 first one are about dbus. The last one is fixed in current implementation Gilles Caulier
Created attachment 88741 [details] Debug statements from Digikam with KExiv2 and KDcraw also I replaced the old debug statements.
Well there is nothing special to see... Just to be sure. - create a new temp account - start digiKam with this account and create a new empty database in this account - add some new images in collection - try to repeat the dysfunction to attribute Tags infinite loop is reproducible ?
I did this and Digikam worked normally. How (short of deleting my database and starting over) can we track this next?
So, i suspect a problem with your SQLite database file (digikam4.db). 2 solutions : - if you have a backup of this file restore it. - if you store metadata to image or sidecar, drop DB file and rescan your collection. DB will be recreated using metadata. Q: do you store your DB file in local file system ? Note : it miss a tool to maintain/consolidate database. There is already a report about this subject. Gilles Caulier
I do store the DB on a local filesystem. The only unexpected shutdowns for Digikam are if it becomes unresponsive, which, till recently, has been rare. Unfortunately, my backups rotate weekly, and this problem has been plaguing me for over a week now. I moved the db files and it has been rebuilding for a while. I have 1.5TB of photos, so this will probably take a bit longer.
I started Digikam rebuilding both thumbnail and metadata databases. It ran for a while and then died. I restarted it, and it again ran for a while and then died. Now, when I start it, it immediately dies. These are the last two lines in the debug message file: digikam(17579)/KEXIV2 KExiv2Iface::KExiv2::Private::printExiv2nnot load metadata using Exiv2 (Error # 11 : /home/ingham/P.3gp: The file contains data of an unknown image type digikam(17579)/KEXIV2 KExiv2Iface::KExiv2::Private::printExiv2nnot load metadata using Exiv2 (Error # 11 : /home/ingham/P.3gp: The file contains data of an unknown image type I can upload the whole message file if needed. Oddly, there is no file /home/ingham/P.3gp, There is a file: /home/ingham/Photos/HawaiiTurtle.3gp: ISO Media, MPEG v4 system, 3GPP That is the only file that ends in 3gp. If I start digikam in gdb, I get the following: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff367fc700 (LWP 22473)] 0x00007fffed455072 in Exiv2::PreviewManager::getPreviewImage(Exiv2::PreviewProperties const&) const () from /usr/lib64/libexiv2.so.12 (gdb) bt #0 0x00007fffed455072 in Exiv2::PreviewManager::getPreviewImage(Exiv2::PreviewProperties const&) const () from /usr/lib64/libexiv2.so.12 #1 0x00007ffff5ca6512 in KExiv2Iface::KExiv2Previews::data(int) () from /usr/lib64/libkexiv2.so.11 #2 0x00007ffff5ca676b in KExiv2Iface::KExiv2Previews::image(int) () from /usr/lib64/libkexiv2.so.11 #3 0x00007ffff529f50d in Digikam::ThumbnailCreator::createThumbnail ( this=this@entry=0x1000a70, info=..., detailRect=...) at /usr/src/debug/digikam-4.3.0/core/libs/threadimageio/thumbnailcreator.cpp:528 #4 0x00007ffff52a21a6 in Digikam::ThumbnailCreator::load (this=0x1000a70, path=..., rect=..., pregenerate=pregenerate@entry=true) at /usr/src/debug/digikam-4.3.0/core/libs/threadimageio/thumbnailcreator.cpp:261 #5 0x00007ffff52a2af0 in Digikam::ThumbnailCreator::pregenerate ( this=<optimized out>, path=...) at /usr/src/debug/digikam-4.3.0/core/libs/threadimageio/thumbnailcreator.cpp:184 #6 0x00007ffff52b14a0 in Digikam::ThumbnailLoadingTask::execute ( this=0x6606a10) at /usr/src/debug/digikam-4.3.0/core/libs/threadimageio/thumbnailtask.cpp:82 #7 0x00007ffff52896c6 in Digikam::LoadSaveThread::run (this=0x11a6950) at /usr/src/debug/digikam-4.3.0/core/libs/threadimageio/loadsavethread.cpp:136 #8 0x00007ffff52b76be in Digikam::DynamicThread::DynamicThreadPriv::run ( this=0x1304ba0) at /usr/src/debug/digikam-4.3.0/core/libs/threads/dynamicthread.cpp:186 #9 0x00007ffff14c913e in ?? () from /usr/lib64/libQtCore.so.4 #10 0x00007ffff14d568f in ?? () from /usr/lib64/libQtCore.so.4 #11 0x00007fffee63e0db in start_thread () from /lib64/libpthread.so.0 #12 0x00007ffff06ee58d in clone () from /lib64/libc.so.6 (gdb)
See this file about your crash : https://bugs.kde.org/show_bug.cgi?id=339144 Gilles Caulier
Based on that bug, I went back to Digikam 4.2, which does start up without crashing. The infinite loop problem appears to still be there when I try to add metadata to a photo such as copyright information. I removed the previous metadata and thumbnail databases, just in case they were corrupt, and I am rebuilding the databases now.
4.2 dies the same way as 4.3. Unless there is another suggestion about how to resolve this, I am about to start the download and build from source process to see if the problem still occurs in the current version.
Created attachment 88888 [details] Digikam log info trace Debug trace from OpenSUSE digikam digikam-4.3.0-24.1.x86_64
Digikam is still going into the infinite loop when I try to tag a photo. I just uploaded the debug log from a test start this morning.
The infinite loop also occurs when trying to search. How can I get more useful information for tracking this down? It makes Digikam unusable.
There is nothing special to see in your backtrace. All sound fine for me. If i'm not too wrong, it look like you turn on Color Management in digiKam. Try to turn off this feature to see if this fix the problem. Gilles Caulier
Turning off color management did not change the problem. However, upgrading to OpenSUSE 13.2 appears to have solved this problem. My best guess is an incompatible shared library.
ok thanks for the feedback Gilles Caulier