Bug 287646

Summary: Digikam import dialog locks if main window closed. Needs to be killed.
Product: [Applications] digikam Reporter: Cristian Tibirna <tibirna>
Component: Import-MainViewAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: caulier.gilles, tpr
Priority: NOR    
Version: 2.3.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 4.1.0
Sentry Crash Report:

Description Cristian Tibirna 2011-11-26 23:12:15 UTC 
Version:           2.3.0 (using KDE 4.7.3) 
OS:                Linux

I import files (nikon raw and paired jpeg, but I doubt it is relevant) from SD card. If I close main window, the download stops and nothing is active on the import dialog. I have to kill it in order to be able to start a new digikam.

Reproducible: Always

Steps to Reproduce:
Start digikam start an import. Close the main window while the download proceeds.

Actual Results:  
Import dialog locks up.

Expected Results:  
Download should continue and digikam quit properly once the download is finished.
Comment 1 caulier.gilles 2011-11-27 10:21:47 UTC 
can you reproduce the problem to run digiKam through GDB, and see where in source code import dialog continue to run when main window is closed ?

Gilles Caulier
Comment 2 Cristian Tibirna 2011-11-27 19:34:37 UTC 
It seems I'm not very good with console gdb. The sole relevant bit of trace I get is 

#0  0x00007fffef4d5e6c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007ffff31224bb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQtCore.so.4
#2  0x00007ffff3121d6c in QThread::wait(unsigned long) () from /usr/lib64/libQtCore.so.4

But in kdbg, I can see (and I reconstruct by hand below) that the frames just above these are in the destructor:
Digikam::CameraController::~CameraController()
Digikam::CameraUI::~CameraUI()
QObjectPrivate::deleteChildren()
QWidget::~QWidget()
Digikam::DigikamApp::~DigikamApp()
QObject::event()

(the event having to be my quit request -- which I did by the windowmanger close button)

Conclusion: threads lock. I would have to learn how to observe threads in a debugger (... yes, I know...). I wasn't able to extract anything intelligent from gdb or kdbg related to this.

Merci pour la compréhension.
Comment 3 caulier.gilles 2012-06-22 08:50:40 UTC 
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
Comment 4 Cristian Tibirna 2012-06-24 05:22:47 UTC 
Unfortunately I can't compile and test 2.6 right now. But with 2.5.0 on KDE 4.8.4 release 513 (OpenSUSE 12.1 rpms) I can still reproduce the lock.
Comment 5 Cristian Tibirna 2012-06-24 05:23:29 UTC 
Unfortunately I can't compile and test 2.6 right now. But with 2.5.0 on KDE 4.8.4 release 513 (OpenSUSE 12.1 rpms) I can still reproduce the lock.
Comment 6 Teemu Rytilahti 2014-01-02 09:00:24 UTC 
Confirmed with current master. Relevant code:
void FileActionMngr::shutDown()
{
    d->dbWorker->deactivate();
    d->fileWorker->deactivate();
    d->dbWorker->wait();
    d->fileWorker->wait(); <-- this causes it to hang.
}

Tried passing WorkerObject::PhaseOut to deactivate(), but it didn't help.
Comment 7 caulier.gilles 2014-05-16 07:29:28 UTC 
digiKam 4.0.0 is out :

http://www.digikam.org/node/713

Please check if this entry still valid with this new version.

Thanks in advance

Gilles Caulier
Comment 8 caulier.gilles 2014-05-24 06:16:17 UTC 
With last digiKam 4.0.0, closing AlbumGUI during downloading, download processing continue until it finished. digiKam do not crash and close properly at end...

I close this file now.

Gilles Caulier
Comment 9 Cristian Tibirna 2014-05-25 21:11:19 UTC 
Very sorry for the delay on this. Indeed, the problem reported is fixed with digikam-4.0.0. Thanks a lot for taking care of this.