Version: 0.9.0-rc2 (using KDE KDE 3.5.5) Installed from: Gentoo Packages OS: Linux When I quickly click on the 'Previous' and 'Next' toolbar buttons, I can reproducibly crash DigiKam. All it takes is pressing 'Next' and clicking 'Previous' while the next image is still loading. Repeat that three or four times and DigiKam dies. I use Exiv 0.12. Backtrace: Using host libthread_db library "/lib/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1238518096 (LWP 9459)] [New Thread -1247765600 (LWP 9678)] [KCrash handler] #6 0xb7dd1cbc in Digikam::SharedLoadingTask::setStatus (this=0x860f720, status=Digikam::LoadingTask::LoadingTaskStatusStopping) at loadsavetask.cpp:315 #7 0xb7dd2caa in Digikam::ManagedLoadSaveThread::load (this=0x8299c68, description=@0xbf8146b8, loadingMode=Digikam::ManagedLoadSaveThread::LoadingModeShared, policy=Digikam::ManagedLoadSaveThread::LoadingPolicyFirstRemovePrevious, accessMode=Digikam::LoadSaveThread::AccessModeReadWrite) at managedloadsavethread.cpp:130 #8 0xb7dd2dde in Digikam::SharedLoadSaveThread::load (this=0x8299c68, description=@0xbf81470c, mode=Digikam::LoadSaveThread::AccessModeReadWrite, policy=Digikam::ManagedLoadSaveThread::LoadingPolicyFirstRemovePrevious) at sharedloadsavethread.cpp:34 #9 0xb7e23060 in Digikam::DImgInterface::load (this=0x82275e8, filename=@0xbf8147d0, iofileSettings=0x84cd5b8, parent=0x8193aa8) at dimginterface.cpp:189 #10 0xb7e230ec in Digikam::Canvas::load (this=0x82517c0, filename=@0xbf8147d0, IOFileSettings=0x84cd5b8) at canvas.cpp:422 #11 0xb7e66f9d in Digikam::ImageWindow::slotLoadCurrent (this=0x84df2f0) at imagewindow.cpp:447 #12 0xb7e6bfb1 in Digikam::ImageWindow::slotForward (this=0x84df2f0) at imagewindow.cpp:487 #13 0xb7e73460 in Digikam::ImageWindow::qt_invoke (this=0x84df2f0, _id=107, _o=0xbf8148e8) at imagewindow.moc:189 #14 0xb6b068a9 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #15 0xb6b074fd in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #16 0xb734460e in KAction::activated (this=0x84ea360) at kaction.moc:176 #17 0xb7439112 in KAction::slotActivated (this=0xbf8148e8) at kaction.cpp:1102 #18 0xb7341c7d in KAction::slotButtonClicked (this=0x84ea360, state=139371360) at kaction.cpp:1147 #19 0xb743880f in KAction::qt_invoke (this=0x84ea360, _id=17, _o=0xbf814a10) at kaction.moc:220 #20 0xb6b068a9 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #21 0xb73b6023 in KToolBarButton::buttonClicked (this=0x85a7100, t0=-19, t1=LeftButton) at ktoolbarbutton.moc:154 #22 0xb73b60f3 in KToolBarButton::mouseReleaseEvent (this=0x85a7100, e=0xbf814dec) at ktoolbarbutton.cpp:479 #23 0xb6b3eb8a in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3 #24 0xb73b84fe in KToolBarButton::event (this=0xbf814dec, e=0x85a7100) at ktoolbarbutton.cpp:651 #25 0xb6aa7f17 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #26 0xb6aa8c59 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #27 0xb7170a16 in KApplication::notify (this=0xbf815274, receiver=0x85a7100, event=0xbf814dec) at kapplication.cpp:550 #28 0xb6a48fe2 in QETWidget::translateMouseEvent () from /usr/qt/3/lib/libqt-mt.so.3 #29 0xb6a488af in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3 #30 0xb6a5883a in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #31 0xb6abe5b0 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #32 0xb6abe446 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #33 0xb6aa79af in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #34 0x0804a274 in main (argc=1, argv=0xbf815484) at main.cpp:269
Marcel, Look like the crash sound into threaded image io implementation... Gilles
Created attachment 18924 [details] fix a presumed race condition Please test if this patch fixes your problem. I cannot reproduce the crash here, but there might be a race condition there that I overlooked.
Toogle to VHI. Must be fixed before 0.9.0-final release Gilles
It also seems like RC2 is a lot slower than Beta2. It takes about three seconds to go to the next image, with color management turned off. Does this make sense to you? I might find some time to compile DigiKam from SVN one of these days. I guess the above patch has been committed?
There is a lots of debug statements in the colnsole witch can take a while. If you compile digiKam using --enable-final option, all statements are removed and reactivity is speed up. Gilles
Dik, No, the patch have not been yet commited. I'm waiting your feedback Gilles
I forgot to say that I also experienced this crash 10 days ago. I was not sure if it was related to something wrong with my system or not. But, it was easy to reproduce using shift+mouse-wheel. Anyway, I just tried the patch and it solves the problem ! So, I think you can commit ;-)
Thanks Fabien... Dik, can you confirm please ? Gilles
Bueeeek! Not so fast, I'm a busy dude too.. :) I will remove my Gentoo packages and try a manual compile tonight, stay tuned.
Ok, the patch appears to work for me too. Nice job!
SVN commit 613773 by cgilles: digikam from trunk : Patch from Marcel to fix a race condition in threaded image I/O witch can crash digiKam in image editor. BUG: 138715 M +13 -4 loadsavetask.cpp --- trunk/extragear/graphics/digikam/libs/threadimageio/loadsavetask.cpp #613772:613773 @@ -171,6 +171,8 @@ m_usedProcess->removeListener(this); // wake up the process which is waiting until all listeners have removed themselves lock.wakeAll(); + // set to 0, as checked in setStatus + m_usedProcess = 0; //DDebug() << "SharedLoadingTask " << this << ": waited" << endl; return; } @@ -279,6 +281,8 @@ // wait until all listeners have removed themselves while (m_listeners.count() != 0) lock.timedWait(); + // set to 0, as checked in setStatus + m_usedProcess = 0; } }; @@ -311,10 +315,15 @@ { LoadingCache *cache = LoadingCache::cache(); LoadingCache::CacheLock lock(cache); - // remove this from list of listeners - check in continueQuery() of active thread - m_usedProcess->removeListener(this); - // wake all listeners - particularly this - from waiting on cache condvar - lock.wakeAll(); + + // check for m_usedProcess, to avoid race condition that it has finished before + if (m_usedProcess) + { + // remove this from list of listeners - check in continueQuery() of active thread + m_usedProcess->removeListener(this); + // wake all listeners - particularly this - from waiting on cache condvar + lock.wakeAll(); + } } }