Version: svn (after 10.0 beta8) (using KDE 4.1.0) Compiler: 4.3.2 OS: Linux Installed from: Ubuntu Packages At the first run of a digikam 10.x (compiled from SVN) and migrating from a 9.4 it crashed. On the console I could see this error: digikam(21006) Digikam::SchemaUpdater::updateV4toV5: Returning true from updating to 5 digikam(21006) Digikam::SchemaUpdater::makeUpdates: Success updating to v5 ASSERT: "d->lockCount == 0" in file /home/tommaso/digicomp/svn/graphics/digikam/libs/database/databaseaccess.cpp, line 131 KCrash: Application 'digikam' crashing... While here it is the backtrace of the corresponding thread: #6 0xb7f0d430 in __kernel_vsyscall () #7 0xb507f880 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb5081248 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb6421795 in qt_message_output () from /usr/lib/libQtCore.so.4 #10 0xb6421872 in qFatal () from /usr/lib/libQtCore.so.4 #11 0xb6421915 in qt_assert () from /usr/lib/libQtCore.so.4 #12 0xb7da6437 in Digikam::DatabaseAccess::assertNoLock () at /home/tommaso/digicomp/svn/graphics/digikam/libs/database/databaseaccess.cpp:131 #13 0xb7da159e in Digikam::CollectionManager::updateLocations (this=0x96c1d90) at /home/tommaso/digicomp/svn/graphics/digikam/libs/database/collectionmanager.cpp:1084 #14 0xb7da3600 in Digikam::CollectionManager::refresh (this=0x96c1d90) at /home/tommaso/digicomp/svn/graphics/digikam/libs/database/collectionmanager.cpp:613 #15 0xb7da6ab5 in Digikam::DatabaseAccess::checkReadyForUse ( observer=0x9600b30) at /home/tommaso/digicomp/svn/graphics/digikam/libs/database/databaseaccess.cpp:257 #16 0x082c6c96 in Digikam::ScanController::run (this=0x9600b28) at /home/tommaso/digicomp/svn/graphics/digikam/digikam/scancontroller.cpp:420 #17 0xb64296ae in ?? () from /usr/lib/libQtCore.so.4 #18 0xb554050f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #19 0xb51357ee in clone () from /lib/tls/i686/cmov/libc.so.6
Once I restart digikam it restarts, but then I cannot see any image, and I get the following errors: digikam(32145) Digikam::AlbumLister::slotResult: Failed to list url: "Could not start process Unable to create io-slave: klauncher said: Unknown protocol 'digikamalbums'. ." I'm using digikam from gnome, and instead of installing everything in /usr I installed it in /opt. At the moment I've no digikam working and I cannot access my albums.
Your problem in comment 2 is typical for Ubuntu and results from not finding the ioslave libraries (kio_digikamalbums.so etc.), which are somehow not installed to the right place
I improved things linking everything I found in /opt/lib/kde4 and /opt/share/kde4/{services,servicetypes} in the corresponding paths in /usr. Now I can see the images. But I still have serious problem, but I don't know if they are bugs or just problems with my installation. I asked this on the digikam-users mailing list, but is there a way to tell KDE4 to look for libraries and resources on a different path as well? I installed digikam in /opt because in /usr I just want to have package managed software.
> I asked this on the digikam-users mailing list, but is there a way to tell KDE4 > to > look for libraries and resources on a different path as well? I installed > digikam in /opt because in /usr I just want to have package managed software. There used to be $KDEDIR and $KDEDIRS, dont know if this still works in KDE4. It's usually better to install to directories as found by CMake if you dont have experience with this packaging stuff.
SVN commit 912474 by mwiesweg: Remove assertNoLock, was intended only as temporary check CCBUG: 180342 M +1 -2 collectionmanager.cpp M +0 -6 databaseaccess.cpp M +0 -2 databaseaccess.h WebSVN link: http://websvn.kde.org/?view=rev&revision=912474
The code causing this crash was a temporary crash and is now removed. It could have been a simple race condition. You can retest by removing your digikam4.db (simply restore it later). Please report any problems, or we can close this.
Now it started with no issues. Thank you.
Tommaso, Thanks for the feedback. I close this file now. Gilles Caulier
This problem is relevant of digiKam KIO slaves which have been dropped since 5.0.0 by a multi-threaded interface to query the database. It will never reproducible.