Created attachment 65720 [details] Thread dump Version: 2.3.0 (using KDE 4.7.3) OS: Linux When I start Digikam from quick action when I plug my camera, it hangs during startup. From the backtrace (attached) it looks like there is a deadlock. Reproducible: Didn't try Steps to Reproduce: Click on "Download pictures using Digikam" when the Camera appears on screen. Actual Results: Digikam hangs during startup. Expected Results: Digikam starts.
The command line looks like: digikam --download-from-udi /org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-1
Which camera do you plug ? Do you use gphoto2 camera, as Canon for ex ? Gilles Caulier
I've restarted and the hang-up happens also without the Camera plugged. Anyway, I have gphoto2 camera, Canon PowerShort S60.
I can analyse the problem more in depth, but currently I'm not much familiar with Qt/KDE. I see DatabaseAccess::DatabaseAccess waiting for lock on Thread 1 and from code also an acquired lock on DatabaseAccess::checkReadyForUse on Thread 4. Thread 4 is waiting on some "emit" code (blocking_activate), which I don't know how works. So the problem is that Thread 1 cannot continue, because Thread 4 has the lock. Thread 4 cannot continue, because it waits for something.
I've checked the CollectionManager::updateLocations (Thread 4): The need to have class DatabaseAccessUnlock points to the real problem - the locking is screwed. If there are methods that need to have the database unlocked then they should be called as such. Moreover, the DatabaseAccessUnlock is written for multi-threaded environment. The constructor frees all locks, but there is no guarantee that the lock will be obtained from other thread after the constructor returns. This just cannot work without locking... I think this class is dangerous in the way it cannot actually do what it declares, so it should be removed and the methods fixed. Maybe the CollectionManagerPrivate::listVolumes method could be revised for thread-safety with KDE 4.7 again (according to the comment inside the method).
The important point is that the current thread, which intends to block on an event loop mutex, drops the DatabaseAccess recursive mutex before. Any other thread may acquire the DatabaseAccess mutex at will. It seems that the unlocking does not work though - apparently, the mutex is locked. It's a special case of a Solid event delivered during the startup phase. What we should reconsider is the dependence of CollectionManager on DatabaseAccess as a "big lock", which adds this complexity.
Removing any (unnecessary) dependency from the database access layer looks more than reasonable. From the architecture point of view the database access layer should do the database access and nothing more.
Official digiKam 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier
Works for me with 2.6.0.