Version: 0.9.0-svn (using KDE KDE 3.5.4) Installed from: SuSE RPMs Compiler: gcc version 4.0.2 OS: Linux When hyperthreading is enabled in the BIOS, digikam crashes often and in several situations, eg. when loading images or editing them in IE. There is no special way to reproduce the crashes. I assume, there are some problems in communication between threads. When hyperthreading is disabled, dikigam runs rocksolid. System: SuSE Linux 10.1 uname -a: Linux tharbad 2.6.16.21-0.13-smp #1 SMP Mon Jul 17 17:22:44 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux See #132649 for backtraces.
That's strange. My system is always using hiperthreading, and the 0.9svn doesn't seem to experiment any problem related to the hiperthreading. To me, with a normal use, it's even hard to crash. Could it be that you have a hardware problem or some library conflict?
Indeed, it's strange. But it's the only explanation I found. When I go to the BIOS and enable hyperthreading, digikam is unusable. When I disable it, I can work. All other applications run without any problems. So, for me, a hardware problem is unlikely. Library conflict? Maybe, but what library should I look for?
Ii confirm this problem. tested on 6 computers here. 3 without using hyperthreading, 3 with hyperthreading. Marcel, something is missing in compilation options ? Gilles
I can confirm this bung indeep. Today i have corrected over 100 RAW picture in my computer with HT disable : no crash ! If HT is enable digiKam crash a lot of time, especially with al image plugins with use the image filter QThread class : http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/filters/dimgthreadedfilter.cpp Marcel, are you sure than your last changes in this code is clean ? Note : just a link in Qt ML : http://lists.trolltech.com/qt-interest/2005-05/thread00815-0.html Gilles
*** Bug 132649 has been marked as a duplicate of this bug. ***
Is it always the same backtrace as posted in 132649? Or are there other bts? Unfortunately I don't have a hyperthreading-capable or dual core machine anywhere near, my Pentium M doesnt do it.
I've been reading the backtrace of that issue, I've seen something strange to me: /lib64/libthread_db.so.1. /lib64/libc.so.6 What? lib64? Linux threads (glibc) for a 64 bits machine in a pentium 4? I've never seen that for a 32 bits distro. If I can help doing some testing in my machine just tell me. I have a pentium4 with HT enabled (Gentoo), using the kernel 2.6.17. I don't know which are exactly the actions that I have to do to try to crash it, because I repeat, to me it works fine. I haven't tried raw images.
SVN commit 577999 by cgilles: digikam from trunk : threaded Image plugin dialogs : Change test to check if computation is already in progress to prevent dupplicate event from gui Heiner, please check if this fix improve the stability with MT on your system. Thanks in advance CCBUGS: 133026 M +1 -2 ctrlpaneldlg.cpp M +1 -2 imageguidedlg.cpp --- trunk/extragear/graphics/digikam/libs/dialogs/ctrlpaneldlg.cpp #577998:577999 @@ -287,8 +287,7 @@ void CtrlPanelDlg::slotEffect() { // Computation already in process. - if (d->currentRenderingMode == CtrlPanelDlgPriv::PreviewRendering || - d->currentRenderingMode == CtrlPanelDlgPriv::FinalRendering) + if (d->currentRenderingMode != CtrlPanelDlgPriv::NoneRendering) return; d->currentRenderingMode = CtrlPanelDlgPriv::PreviewRendering; --- trunk/extragear/graphics/digikam/libs/dialogs/imageguidedlg.cpp #577998:577999 @@ -427,8 +427,7 @@ void ImageGuideDlg::slotEffect() { // Computation already in process. - if (d->currentRenderingMode == ImageGuideDlgPriv::PreviewRendering || - d->currentRenderingMode == ImageGuideDlgPriv::FinalRendering) + if (d->currentRenderingMode != ImageGuideDlgPriv::NoneRendering) return; d->currentRenderingMode = ImageGuideDlgPriv::PreviewRendering;
Antonio, The crash is not relevant of 8 or 16 bits color depth images. The crash appear just before to update the preview in plugin dialogs, for example when you change the focus area with Noise Reduction or Refocus tool. I can reproduce also this problem with Free Rotation tool. It another common dialog implementation... In both, the image filter algorithm is forked to a separate thread to unfreeze gui and speed up computation (with HT, we using the second processor to compute algorithms). Note : This is not the case of all "Color" image plugins, like BCG, B&W, WB, or RGB correction tools for example, witch use another one common dialog. This one is not yet ported to use a separate thread with algorithm. I suspect multi-events from gui witch start more than one computation threads at the same time and of course crash digiKam when computations are done (multi-results witch update preview). I don't know why this side effect appear with HT only. Marcel, if you have some ideas... Gilles
Gilles, I've checked your changes, but it doesn't look like it solved the issue. On the 32bit version, I had two crashes within 15 minutes. I'm not sure, if multi-events are realy the reason. The crashes happen, eg. when I move the preview (the rectangle in the small complete view in the upper right) in a filter dialog. But that's not possible, while a computation is running. Backtrace #1: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1239882064 (LWP 23218)] [New Thread -1251243104 (LWP 23230)] [KCrash handler] #6 0xb61faa22 in malloc_consolidate () from /lib/libc.so.6 #7 0xb61fc679 in _int_malloc () from /lib/libc.so.6 #8 0xb61fe206 in malloc () from /lib/libc.so.6 #9 0xb6951716 in QImage::QImage () from /usr/lib/qt3/lib/libqt-mt.so.3 #10 0xb7ede9e3 in Digikam::DImg::convertToPixmap (this=0xbfe8a350) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/dimg.cpp:1174 #11 0xb7edebaa in Digikam::DImg::convertToPixmap (this=0xabdf1e98, monitorICCtrans=0xbfe8a4e4) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/dimg.cpp:1210 #12 0xb7ef93a6 in Digikam::ImageIface::paint (this=0xabdf1e20, device=0xabef1e68, x=0, y=0, w=360, h=240) at /work/heiner/Develop/digikam/unstable/graphics/digikam/utilities/imageeditor/editor/imageiface.cpp:361 #13 0xb7e18741 in Digikam::ImagePanIconWidget::updatePixmap (this=0xae9f1e10) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/widgets/imageplugins/imagepaniconwidget.cpp:194 #14 0xb7e19a97 in Digikam::ImagePanIconWidget::mouseMoveEvent ( this=0xae9f1e10, e=0xbfe8ac34) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/widgets/imageplugins/imagepaniconwidget.cpp:316 #15 0xb69babc4 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #16 0xb6922ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #17 0xb6923dfb in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #18 0xb7066963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #19 0xb68c2dd2 in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #20 0xb68c1fa6 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #21 0xb68d25ea in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #22 0xb6939ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0xb69229ef in QApplication::enter_loop () from /usr/lib/qt3/lib/libqt-mt.so.3 #24 0xb6b084d5 in QDialog::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #25 0xb32a7280 in ImagePlugin_Refocus::slotRefocus (this=0x858f0e8) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.cpp:67 #26 0xb32a72f1 in ImagePlugin_Refocus::qt_invoke (this=0x858f0e8, _id=2, _o=0xbfe8b158) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.moc:82 #27 0xb6981edd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb6982b3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb7248a69 in KAction::activated () from /opt/kde3/lib/libkdeui.so.4 #30 0xb727dea2 in KAction::slotActivated () from /opt/kde3/lib/libkdeui.so.4 #31 0xb736b12d in KAction::slotPopupActivated () from /opt/kde3/lib/libkdeui.so.4 #32 0xb736b3f1 in KAction::qt_invoke () from /opt/kde3/lib/libkdeui.so.4 #33 0xb6981edd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0xb6cbaa9e in QSignal::signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0xb699df87 in QSignal::activate () from /usr/lib/qt3/lib/libqt-mt.so.3 #36 0xb6a895ea in QPopupMenu::mouseReleaseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #37 0xb7251efe in KPopupMenu::mouseReleaseEvent () from /opt/kde3/lib/libkdeui.so.4 #38 0xb69bac00 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #39 0xb6922ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #40 0xb6923dfb in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #41 0xb7066963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #42 0xb68c36ae in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #43 0xb68c1fa6 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #44 0xb68d25ea in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #45 0xb6939ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #46 0xb6939b7e in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #47 0xb6922a7f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #48 0x0804ab2c in main (argc=-1208559796, argv=0x22) at /work/heiner/Develop/digikam/unstable/graphics/digikam/digikam/main.cpp:273 =========================================================================== Backtrace #2: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1240082768 (LWP 23973)] [New Thread -1251443808 (LWP 24009)] [KCrash handler] #6 0xb61cf8fa in strcmp () from /lib/libc.so.6 #7 0xb7051741 in QMapPrivate<KEntryKey, KEntry>::find () from /opt/kde3/lib/libkdecore.so.4 #8 0xb6f76ca9 in KConfig::lookupData () from /opt/kde3/lib/libkdecore.so.4 #9 0xb6fc0b6d in KConfigBase::readEntryUtf8 () from /opt/kde3/lib/libkdecore.so.4 #10 0xb6fc3639 in KConfigBase::readNumEntry () from /opt/kde3/lib/libkdecore.so.4 #11 0xb6fc4b0b in KConfigBase::readNumEntry () from /opt/kde3/lib/libkdecore.so.4 #12 0xb6fc4ecb in kdbgstream::flush () from /opt/kde3/lib/libkdecore.so.4 #13 0xb7cb359b in kdbgstream::operator<< (this=0xbfcc9830, string=0xb7ef65a0 "\n") at /opt/kde3/include/kdebug.h:232 #14 0xb7cb35d1 in endl (s=@0xbfcc9830) at /opt/kde3/include/kdebug.h:430 #15 0xb7caf949 in kdbgstream::operator<< (this=0xbfcc9830, f=0xb7cb35aa <endl(kdbgstream&)>) at /opt/kde3/include/kdebug.h:260 #16 0xb7e990d3 in Digikam::IccTransform::apply (this=0xbfcc9b24, image=@0xbfcc9990) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/filters/icctransform.cpp:247 #17 0xb7eadb98 in Digikam::DImg::convertToPixmap (this=0x860a4c8, monitorICCtrans=0xbfcc9b24) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/dimg.cpp:1207 #18 0xb7ec83a6 in Digikam::ImageIface::paint (this=0x860a450, device=0x860a678, x=0, y=0, w=360, h=240) at /work/heiner/Develop/digikam/unstable/graphics/digikam/utilities/imageeditor/editor/imageiface.cpp:361 #19 0xb7de7741 in Digikam::ImagePanIconWidget::updatePixmap (this=0x860a230) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/widgets/imageplugins/imagepaniconwidget.cpp:194 #20 0xb7de8a97 in Digikam::ImagePanIconWidget::mouseMoveEvent (this=0x860a230, e=0xbfcca274) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/widgets/imageplugins/imagepaniconwidget.cpp:316 #21 0xb6989bc4 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #22 0xb68f1ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0xb68f2dfb in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #24 0xb7035963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #25 0xb6891dd2 in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #26 0xb6890fa6 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #27 0xb68a15ea in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb6908ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb68f19ef in QApplication::enter_loop () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0xb6ad74d5 in QDialog::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0xb3276280 in ImagePlugin_Refocus::slotRefocus (this=0x858c3f0) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.cpp:67 #32 0xb32762f1 in ImagePlugin_Refocus::qt_invoke (this=0x858c3f0, _id=2, _o=0xbfcca798) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.moc:82 #33 0xb6950edd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0xb6951b3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0xb7217a69 in KAction::activated () from /opt/kde3/lib/libkdeui.so.4 #36 0xb724cea2 in KAction::slotActivated () from /opt/kde3/lib/libkdeui.so.4 #37 0xb733a12d in KAction::slotPopupActivated () from /opt/kde3/lib/libkdeui.so.4 #38 0xb733a3f1 in KAction::qt_invoke () from /opt/kde3/lib/libkdeui.so.4 #39 0xb6950edd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #40 0xb6c89a9e in QSignal::signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #41 0xb696cf87 in QSignal::activate () from /usr/lib/qt3/lib/libqt-mt.so.3 #42 0xb6a585ea in QPopupMenu::mouseReleaseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #43 0xb7220efe in KPopupMenu::mouseReleaseEvent () from /opt/kde3/lib/libkdeui.so.4 #44 0xb6989c00 in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #45 0xb68f1ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #46 0xb68f2dfb in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #47 0xb7035963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #48 0xb68926ae in QETWidget::translateMouseEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #49 0xb6890fa6 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #50 0xb68a15ea in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #51 0xb6908ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #52 0xb6908b7e in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #53 0xb68f1a7f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #54 0x0804ab2c in main (argc=-1208760500, argv=0x22) at /work/heiner/Develop/digikam/unstable/graphics/digikam/digikam/main.cpp:273
Heiner, The computation is started when you release the left mouse button (in the case of Refocus dialog) Is digiKam crash also when you move the preview content to change the focus area ? With the second backtrace, you have enabled screen Color Management. I recommend you to disable it for these investigaution, else we will cumulate the problem to solve. We will look this problem later. Gilles
Gilles, IIRC, digikam never crashed while only moving the rectangle. Heiner
Okay, I disabled CMS. Testing gave me two more backtraces. The first one occured when closing the application, the second again with refocus filter. Heiner ========================================================================== Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1240521040 (LWP 9701)] [KCrash handler] #6 0xd0b6b895 in ?? () #7 0xb6927e64 in QVariant::Private::clear () from /usr/lib/qt3/lib/libqt-mt.so.3 #8 0xb692842d in QVariant::Private::~Private () from /usr/lib/qt3/lib/libqt-mt.so.3 #9 0xb69285c5 in QVariant::~QVariant () from /usr/lib/qt3/lib/libqt-mt.so.3 #10 0xb7dd8b8a in ~QMapNode (this=0x82d2a00) at /usr/lib/qt3/include/qmap.h:84 #11 0xb7dd9834 in QMapPrivate<QString, QVariant>::clear (this=0x81c7158, p=0x82d2a00) at /usr/lib/qt3/include/qmap.h:490 #12 0xb7dd987c in QMapPrivate<QString, QVariant>::clear (this=0x81c7158) at /usr/lib/qt3/include/qmap.h:477 #13 0xb7dd98dd in ~QMapPrivate (this=0x81c7158) at /usr/lib/qt3/include/qmap.h:371 #14 0xb7dd9944 in ~QMap (this=0x8222988) at /usr/lib/qt3/include/qmap.h:644 #15 0xb7e44d94 in ~DImgPrivate (this=0x8222970) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/dimgprivate.h:59 #16 0xb7e41ad2 in ~DImg (this=0x82c4f70) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/dimg/dimg.cpp:103 #17 0xb7dbc986 in QCache<Digikam::DImg>::deleteItem (this=0x874d1a8, d=0x82c4f70) at /usr/lib/qt3/include/qcache.h:90 #18 0xb6b97ebf in QGCache::clear () from /usr/lib/qt3/lib/libqt-mt.so.3 #19 0xb7dbc8ef in QCache<Digikam::DImg>::clear (this=0x874d1a8) at /usr/lib/qt3/include/qcache.h:66 #20 0xb7dbcb01 in ~QCache (this=0x874d1a8) at /usr/lib/qt3/include/qcache.h:57 #21 0xb7dbcb6d in ~LoadingCachePriv (this=0x874d1a8) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/threadimageio/loadingcache.cpp:28 #22 0xb7dbc567 in ~LoadingCache (this=0x86fa538) at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/threadimageio/loadingcache.cpp:65 #23 0xb7dbc5be in Digikam::LoadingCache::cleanUp () at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/threadimageio/loadingcache.cpp:50 #24 0xb7dbceb5 in Digikam::LoadingCacheInterface::cleanUp () at /work/heiner/Develop/digikam/unstable/graphics/digikam/libs/threadimageio/loadingcacheinterface.cpp:30 #25 0xb7c6c10e in ~DigikamApp (this=0x8117f70) at /work/heiner/Develop/digikam/unstable/graphics/digikam/digikam/digikamapp.cpp:189 #26 0xb68e58a8 in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #27 0xb691e88c in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb69d9982 in QMainWindow::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb6886ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0xb6887cb9 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0xb6fca963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #32 0xb6888880 in QApplication::sendPostedEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0xb689dd79 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0xb689db7e in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0xb6886a7f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #36 0x0804ab2c in main (argc=-1209198772, argv=0x22) at /work/heiner/Develop/digikam/unstable/graphics/digikam/digikam/main.cpp:273 ========================================================================== Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1240349008 (LWP 12501)] [New Thread -1243317344 (LWP 12944)] [New Thread -1251710048 (LWP 12579)] 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb61dbd11 in ___newselect_nocancel () from /lib/libc.so.6 #2 0xb68603b6 in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #3 0xb68c7ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #4 0xb68b09ef in QApplication::enter_loop () from /usr/lib/qt3/lib/libqt-mt.so.3 #5 0xb6a964d5 in QDialog::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #6 0xb3235280 in ImagePlugin_Refocus::slotRefocus (this=0x858e400) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.cpp:67 #7 0xb32352f1 in ImagePlugin_Refocus::qt_invoke (this=0x858e400, _id=2, _o=0xbfe5c2a8) at /work/heiner/Develop/digikam/unstable/graphics/digikamimageplugins/refocus/imageplugin_refocus.moc:82 #8 0xb690fedd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #9 0xb6910b3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #10 0xb71d6a69 in KAction::activated () from /opt/kde3/lib/libkdeui.so.4 #11 0xb720bea2 in KAction::slotActivated () from /opt/kde3/lib/libkdeui.so.4 #12 0xb72f93df in KAction::qt_invoke () from /opt/kde3/lib/libkdeui.so.4 #13 0xb690fedd in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #14 0xb6910b3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #15 0xb6f0eb29 in KAccelPrivate::menuItemActivated () from /opt/kde3/lib/libkdecore.so.4 #16 0xb6f5e9d7 in KAccelPrivate::emitActivatedSignal () from /opt/kde3/lib/libkdecore.so.4 #17 0xb6fe9e39 in KAccelPrivate::eventFilter () from /opt/kde3/lib/libkdecore.so.4 #18 0xb690f7dc in QObject::activate_filters () from /usr/lib/qt3/lib/libqt-mt.so.3 #19 0xb690f84b in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #20 0xb694888c in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #21 0xb6a03982 in QMainWindow::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #22 0xb68b0ec7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0xb68b2222 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #24 0xb6ff4963 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 #25 0xb6f6a722 in KAccelEventHandler::x11Event () from /opt/kde3/lib/libkdecore.so.4 #26 0xb6ff27ab in KApplication::x11EventFilter () from /opt/kde3/lib/libkdecore.so.4 #27 0xb683fdc4 in qt_x11EventFilter () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb684f733 in QApplication::x11ProcessEvent () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb68605ea in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0xb68c7ce8 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0xb68c7b7e in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #32 0xb68b0a7f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0x0804ab2c in main (argc=-1209026740, argv=0x22) at /work/heiner/Develop/digikam/unstable/graphics/digikam/digikam/main.cpp:273 Last messages on console: digikam: Preview refocus started... digikam: Refocus::Start of computation... digikam: Refocus::Compute matrix... digikam: Refocus::Apply Matrix to image... digikam: Preview refocus completed... digikam: Refocus::End of computation !!! ... ( 2 s ) digikam: Preview refocus started... digikam: Refocus::Start of computation... KCrash: Application 'digikam' crashing... QSocketNotifier: invalid socket 19 and type 'Read', disabling... QSocketNotifier: invalid socket 17 and type 'Read', disabling... QSocketNotifier: invalid socket 14 and type 'Read', disabling... QSocketNotifier: invalid socket 9 and type 'Read', disabling... QSocketNotifier: invalid socket 18 and type 'Read', disabling... QSocketNotifier: invalid socket 11 and type 'Read', disabling... QSocketNotifier: invalid socket 15 and type 'Read', disabling... QSocketNotifier: invalid socket 6 and type 'Read', disabling... digikam: Fatal IO error: client killed
Created attachment 17537 [details] debug statements All these backtraces are strange and do not seem to be related to moving the rectangle in the refocus plugin...I dont trust bts too much. I have created a patch which adds a lot more bts to some relevant parts (for crashing when moving the focus rectangle in the Refocus plugin), perhaps we can find the location where the crash happens. That's the only idea I currently have. Btw, are all those plugins using the CtrlPanelDlg or is this not correlated?
Yes, all : refocus, unsharp mask, noise reduction etc... and also all plugins witch use imageguidedlg dialog implementation (free rotation for example) The both dialogs use the threaded image filter class. I'm sure, i can reproduce the problem here, on my wife's computer : PIV-3.2 Ghz, 500Mb with hyperthreading. I have seen that more cpu is speed, more the problem is reproductible. For example, at work, i have another PIV HT computer where i have decreased the cpu speed, and in this case, the crash is more difficult to reproduce. Of course, if i disable HT, the crash do not appear. I have tested under Mandriva 2005-2006 and Suse 10.1. The crash sound like an disynchronism, or something like that. Marcel, are you seen in amarok : there is a method to controling HT : http://websvn.kde.org/trunk/extragear/multimedia/amarok/src/app.cpp?rev=576765&view=auto ... look void App::fixHyperThreading() method... Gilles
Very intructive story from amarok : http://bugs.kde.org/show_bug.cgi?id=99199 Gilles
It seems to me that the bug has been fixed. I stressed digiKam for 2 days now with the notorious plugins and it was rock-stable.
Gerhard, Are you sure to haven't changed/updated something in your computer, like kernel or/and libc ? Friendly Gilles
Well I upgrade my system every day (which is stupid, but I learn a lot). But libc I didn't updatefor 2 weeks and I'm running 2.6.17.8 #1 SMP PREEMPT Mon Aug 7 16:09:42 CEST 2006 i686 GNU/Linux. With refocus plugin I could reliably crash digiKam by trying about 5 different settings before applying it to the image. Now I tried 20 times on several images in a row without problem. It's not a hard prove but a big difference. Gerhard
El Mi
Antonio, You said that all work fine for you. Witch kernel and glibc release you use on your 32 bits HT computer ? Gilles
Heiner, I suspect a problem relevant of glibc and/or kernel. I have talking with some multithreading guru under linux at work, and this problem is know with PIV-HT CPU computers, not with _real_ multi-CPU computers. Perhaps you can solve the problem to update kernel and libc, if you can... Gilles
I'm pretty sure that such issues (as in this bug report just as in Amarok's case - http://bugs.kde.org/show_bug.cgi?id=99199) are not cause by hyperthreading. Instead, hyperthreading exposes other issues (unsafe use of QStrings - the reference counter for its implicit sharing might be accessed simultaneously from multiple threads, ...) in the code. One possible explanation why mere SMP systems (and hyperthreading should appear to the application just as such a system) don't trigger these bugs so often could be the following: - in a SMP system, when the same memory address is accessed (for writing) from multiple, the corresponding cache line has to be committed from the CPU's cache back to main memory and ownership has to be transferred to the other CPU wanting to write - a relatively slow process - in a hyperthreading system, this does not have to happen, as there is only one CPU with only one cache, it's just that this CPU is used by two threads almost simultaneously, as control shifts from one virtual CPU to the other without OS intervention very very often I think this can increase the probability of two threads accessing the same memory address at the same time quite a lot. I hope that Qt4 will make these kind of problems mostly go away, as the implicit sharing will be really invisible to the user. In Qt3 you have to use QDeepCopy when passing QStrings between threads - which is really painful to get right in all cases.
After the latests svn updates I have started to experience this problem with some image filters. Yesterday it crashes at least 3 or 4 times. Maybe it didn't happen before just for a coincidence. I'll try to attach backtraces.
Here I have one, I don't know if it's useful 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 -1241680208 (LWP 9496)] [New Thread -1241994336 (LWP 9536)] [New Thread -1250387040 (LWP 9509)] 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb60cd94e in pthread_exit () from /lib/libc.so.6 #2 0xb61f1929 in operator delete () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 #3 0xb6b41b51 in QGList::removeRef () from /usr/qt/3/lib/libqt-mt.so.3 #4 0xb6855fc4 in QApplication::sendPostedEvents () from /usr/qt/3/lib/libqt-mt.so.3 #5 0xb68561a8 in QApplication::sendPostedEvents () from /usr/qt/3/lib/libqt-mt.so.3 #6 0xb6806ade in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb686a22d in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #8 0xb6854437 in QApplication::enter_loop () from /usr/qt/3/lib/libqt-mt.so.3 #9 0xb6a20331 in QDialog::exec () from /usr/qt/3/lib/libqt-mt.so.3 #10 0xb3e19bd8 in ImagePlugin_Emboss::slotEmboss () from /usr/kde/3.5/lib/kde3/digikamimageplugin_emboss.so #11 0xb3e19c40 in ImagePlugin_Emboss::qt_invoke () from /usr/kde/3.5/lib/kde3/digikamimageplugin_emboss.so #12 0xb68aeeb0 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #13 0xb68af9f0 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #14 0xb7197259 in KAction::activated () from /usr/kde/3.5/lib/libkdeui.so.4 #15 0x00000002 in ?? () #16 0xb7361884 in ?? () from /usr/kde/3.5/lib/libkdeui.so.4 #17 0xb7197360 in KAction::slotActivated () from /usr/kde/3.5/lib/libkdeui.so.4 #18 0xb7361884 in ?? () from /usr/kde/3.5/lib/libkdeui.so.4 #19 0xb7361884 in ?? () from /usr/kde/3.5/lib/libkdeui.so.4 #20 0xb6cd5200 in vtable for QPopupMenu () from /usr/qt/3/lib/libqt-mt.so.3 #21 0xffffff15 in ?? () #22 0xb719c4d1 in KAction::slotPopupActivated () from /usr/kde/3.5/lib/libkdeui.so.4 #23 0xbf93f08c in ?? ()
There's a message that I get dozens of time in the console everytime that a preview is made in a filter like for example Emboss Image: QFile::open: No file name specified Maybe is unrelated, but what's trying to open more than 12 times for a previsualization? Probably it's normal, but I want to post it just in case that gives a little hint to everybody about the origin of the crashes.
The QFile::open messages are emitted from Qt when the QPixmap constructor is called with a file name. It is perfectly all right to call the constructor with a file name, and it works, I don't know why there are these messages.
SVN commit 599179 by cgilles: digikam from trunk : make a deep copy of QString in threaded image filter constructor to prevent crash into Hyperthreading CPU. To digiKam users : feedback is welcome... CCBUGS:133026 CCMAIL: digikam-devel@kde.org M +33 -25 dimgthreadedfilter.cpp M +33 -31 dimgthreadedfilter.h --- trunk/extragear/graphics/digikam/libs/dimg/filters/dimgthreadedfilter.cpp #599178:599179 @@ -1,5 +1,4 @@ /* ============================================================ - * File : dimgthreadedfilter.cpp * Author: Gilles Caulier <caulier dot gilles at kdemail dot net> * Date : 2005-05-25 * Description : threaded image filter class. @@ -24,6 +23,7 @@ #include <qobject.h> #include <qdatetime.h> #include <qevent.h> +#include <qdeepcopy.h> // KDE includes. @@ -36,34 +36,42 @@ namespace Digikam { -DImgThreadedFilter::DImgThreadedFilter(DImg *orgImage, QObject *parent, QString name) +DImgThreadedFilter::DImgThreadedFilter(DImg *orgImage, QObject *parent, + const QString& name) : QThread() { // remove meta data - m_orgImage = orgImage->copyImageData(); - m_parent = parent; - m_cancel = false; - m_name = name; + m_orgImage = orgImage->copyImageData(); + m_parent = parent; + m_cancel = false; - m_master = 0; - m_slave = 0; + // See B.K.O #133026: make a deep copy of Qstring to prevent crash + // on Hyperthreading computer. + m_name = QDeepCopy<QString>(name); + + m_master = 0; + m_slave = 0; m_progressBegin = 0; m_progressSpan = 100; } -DImgThreadedFilter::DImgThreadedFilter(DImgThreadedFilter *master, const DImg &orgImage, const DImg &destImage, - int progressBegin, int progressEnd, QString name) +DImgThreadedFilter::DImgThreadedFilter(DImgThreadedFilter *master, const DImg &orgImage, + const DImg &destImage, int progressBegin, int progressEnd, + const QString& name) { - m_orgImage = orgImage; - m_destImage = destImage; - m_parent = 0; - m_cancel = false; - m_name = name; + m_orgImage = orgImage; + m_destImage = destImage; + m_parent = 0; + m_cancel = false; - m_master = master; - m_slave = 0; + // See B.K.O #133026: make a deep copy of Qstring to prevent crash + // on Hyperthreading computer. + m_name = QDeepCopy<QString>(name); + + m_master = master; + m_slave = 0; m_progressBegin = progressBegin; - m_progressSpan = progressEnd - progressBegin; + m_progressSpan = progressEnd - progressBegin; m_master->setSlave(this); } @@ -75,8 +83,6 @@ m_master->setSlave(0); } - - void DImgThreadedFilter::initFilter(void) { m_destImage.reset(); @@ -123,9 +129,9 @@ else if (m_parent) { EventData *eventData = new EventData(); - eventData->progress = progress; - eventData->starting = starting; - eventData->success = success; + eventData->progress = progress; + eventData->starting = starting; + eventData->success = success; QApplication::postEvent(m_parent, new QCustomEvent(QEvent::User, eventData)); } } @@ -150,7 +156,8 @@ postProgress(0, false, true); kdDebug() << m_name - << "::End of computation !!! ... ( " << startDate.secsTo(endDate) << " s )" << endl; + << "::End of computation !!! ... ( " << startDate.secsTo(endDate) << " s )" + << endl; } else { @@ -158,7 +165,8 @@ postProgress(0, false, false); kdDebug() << m_name - << "::Computation aborted... ( " << startDate.secsTo(endDate) << " s )" << endl; + << "::Computation aborted... ( " << startDate.secsTo(endDate) << " s )" + << endl; } } --- trunk/extragear/graphics/digikam/libs/dimg/filters/dimgthreadedfilter.h #599178:599179 @@ -1,5 +1,4 @@ /* ============================================================ - * File : dimgthreadedfilter.h * Author: Gilles Caulier <caulier dot gilles at kdemail dot net> * Date : 2005-05-25 * Description : threaded image filter class. @@ -46,8 +45,7 @@ public: -// Class used to post status of computation to parent. - +/** Class used to post status of computation to parent. */ class EventData { public: @@ -65,7 +63,8 @@ public: - DImgThreadedFilter(DImg *orgImage, QObject *parent=0, QString name=QString::null); + DImgThreadedFilter(DImg *orgImage, QObject *parent=0, + const QString& name=QString::null); ~DImgThreadedFilter(); @@ -78,49 +77,44 @@ protected: - // Copy of original Image data. + /** Copy of original Image data. */ DImg m_orgImage; - // Output image data. + /** Output image data. */ DImg m_destImage; - // Filter name. + /** Filter name.*/ QString m_name; - // Used to stop compution loop. + /** Used to stop compution loop. */ bool m_cancel; - // To post event from thread to parent. + /** To post event from thread to parent. */ QObject *m_parent; protected: - // Start filter operation before threaded method. Must be calls by your constructor. + /** Start filter operation before threaded method. Must be calls by your constructor. */ virtual void initFilter(void); - // List of threaded operations by filter. + /** List of threaded operations by filter. */ virtual void run(){ startComputation(); }; - // Main image filter method. + /** Main image filter method. */ virtual void filterImage(void){}; - // Clean up filter data if necessary. Call by stopComputation() method. + /** Clean up filter data if necessary. Call by stopComputation() method. */ virtual void cleanupFilter(void){}; - // Post Event to parent about progress. Warning: you need to delete - // 'EventData' instance to 'customEvent' parent implementation. + /** Post Event to parent about progress. Warning: you need to delete + 'EventData' instance to 'customEvent' parent implementation. */ void postProgress(int progress=0, bool starting=true, bool success=false); - + protected: - // Support for chaining two filters as master and thread + /** + Support for chaining two filters as master and thread. - // The current slave. Any filter might want to use another filter while processing. - DImgThreadedFilter *m_slave; - // The master of this slave filter. Progress info will be routed to this one. - DImgThreadedFilter *m_master; - - /* Constructor for slave mode: Constructs a new slave filter with the specified master. The filter will be executed in the current thread. @@ -129,20 +123,28 @@ that the slave filter uses in the parent filter's progress. Any derived filter class that is publicly available to other filters should implement an additional constructor using this constructor. - */ + */ DImgThreadedFilter(DImgThreadedFilter *master, const DImg &orgImage, const DImg &destImage, - int progressBegin=0, int progressEnd=100, QString name=QString::null); + int progressBegin=0, int progressEnd=100, const QString& name=QString::null); - // inform the master that there is currently a slave. At destruction of the slave, call with slave=0. + /** Inform the master that there is currently a slave. At destruction of the slave, call with slave=0. */ void setSlave(DImgThreadedFilter *slave); - // The progress span that a slave filter uses in the parent filter's progress + /** This method modulates the progress value from the 0..100 span to the span of this slave. + Called by postProgress if master is not null. */ + virtual int modulateProgress(int progress); + +protected: + + /** The current slave. Any filter might want to use another filter while processing. */ + DImgThreadedFilter *m_slave; + + /** The master of this slave filter. Progress info will be routed to this one. */ + DImgThreadedFilter *m_master; + + /** The progress span that a slave filter uses in the parent filter's progress. */ int m_progressBegin; int m_progressSpan; - // This method modulates the progress value from the 0..100 span to the span of this slave. - // Called by postProgress if master is not null. - virtual int modulateProgress(int progress); - }; } // NameSpace Digikam
Hey guy ! I think that i have fixed the problem under current implementation of digiKam core by this commit : http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/filters/dimgthreadedfilter.cpp?rev=599227&r1=599179&r2=599227 Here i have 3 computers running with PIV-3.4Ghz HT CPU and Mandriva 2006, Mandriva 2007, and Suse 10.1. if i revert this commit, digiKam crash when i use a threaded image filter like UnsharpMask tool. If i use the current implementation i cannot reproduce the crash ! The question is why KDebug() cannot be used i a separate thread forked in a HyperThreading CPU. Martin, Marcel, all suggestions welcome. Please, please, please, give me a feedback. Note than you need to recompile/install digiKam _and_ DigikamImagePlugins for that. Thanks in advance for your reports... Gilles Caulier
The m_name is already a QDeepCopy, so it cannot be the reason. There could be a bug in kdelibs. Another answer is possible as well: The debug statements take relatively long time. Removing them can change the timing in such a way that a completely unrelated problem disappears.
I tried this commit for several hours using unsharp and refocus tools on a Debian/experimental P4 hyperthreaded system with no crash. Before it crashed very quickly. So I think the problem is solved. Gerhard
I've tried it and it didn't crash in my tests, so I think that the problem is fixed. Great work!
Antonio, Yes the problem can be considered like temporaly fixed in digiKam (from user viewpoint), but not for me... Like Marcel said, why a KDebug() statement used this class crash digiKam ? This class use QThread to fork in a separate thread all computations performed in image data. In another digiKam part, we using also QThread with some KDebug() statement, especially to load image data from picture files and, fix me if i'm wrong, digiKam do not crash in this part why HT CPU (i can't reproduce it in my computers here)... ...Perhaps i can explain that because loading a image from a file is a slow process instead a computation in memory is always more faster. Using KDebug() in image loading process don't perturb something for that. Marcel, can we considerate than KDebug() can not be multithreaded ? Source code of KDebug class is here : http://websvn.kde.org/branches/KDE/3.5/kdelibs/kdecore/kdebug.cpp?rev=578150&view=auto Gilles Caulier
Created attachment 18303 [details] Stress test kdDebug() I did not yet take a closer look at the source. Attached is a stress test for kdDebug() using 100 threads. Of course, only if this produces a crash it shows that there is a problem with kdDebug, if it does not crash this shows nothing.
(sigh). People, kdelibs are not threadsafe, and are not claimed to be threadsafe anywhere.
Marcel, i will try you test program in my office monday morning. Maksim, do you confirm than the crash is probably relevant of using KDebug() statement in a QThread ? Also, there is a plan to fix some kdelib part to be threadsafe with KDE 4.0 (especially KDebug class) ? Marcel, if KDebug is not threadsafe, we can use QDebug instead where it's necessary to post debug messages in the console from separate thread implementation. Right ? Gilles
On Thursday 26 October 2006 20:24, Gilles Caulier wrote: > > ------- Additional Comments From caulier.gilles kdemail net > 2006-10-26 20:24 ------- Hey guy ! > > I think that i have fixed the problem under current > implementation of digiKam core by this commit : I did my best during the weekend, but could not reproduce the problem anymore. So, for me, it's fixed. Thanks, Heiner
Marcel, I have executed your KDebug test program under my 3 HT computers... and it crash everywhere in libc after to post some messages in the console. Conclusion : we _NEVER_ use KDebug in QThread !!! I think this is an hight limitation of KDELib ! All KDElib API witch are non relevant of GUI, especially to debug an application must be thread-safe. I close this file about digiKam, but i recommend to report this information to KDELib developpers team. Gilles Caulier
Marcel, I have another question for you : We using a lot of KDebug statements in DImg/Dmetadata API witch are multithreaded by digiKam... What do you think about ? We need to use QDebug instead everywhere ? Is Amarok use QDebug instead KDebug in multithreaded implementation ? Gilles
Taking a closer look at kdebug.cpp, the function kDebugBackend(): it uses a global, static variable. Yes, I think we should not use kdDebug anywhere outside the main thread from now. I see four possibilities, for the 0.9.0 release: - remove all kdDebug in multithreaded code - use qDebug - write a thin wrapper around kdDebug using a mutex - write a replacement for kdDebug which is reentrant. Copy over all the nice operator<< implementations.
Marcel, Under KDevelop, searching all KDdebug() statements in digikam/libs give around 400 hits. Also, the camera interface is multithreaded. We need to fix this part too. In fact to be sure, i would to fix all KDdebug() statements in digiKam _and_ DigikamImagePlugins _and_ Kipi-plugins (where there is also some multithreaded parts). I vote to write a thin wrapper around kDdebug using a mutex. I think it's the more simple to do... To have look like QDebug() work, it's completly different and require a lot of work. I'm not agree to remove all KDebug() statments because it's a good report to investiguate indeep problems. I think to write a replacement for KDdebug which is reentrant must be done by kdelibs developpers, not digiKam team (:=)))... To fix kipi-plugins, the wrapper around kDdebug() using a mutex must be backported to the kipi-plugins/common/libkipiplugins. Gilles
Created attachment 18389 [details] Test kdDebug wrapper The attached file contains the same stress test, this time using a thin wrapper around kdDebug. The implementation should be tested on affected systems before we continue.
Thanks Marcel. I will take a look be only Monday morning because my HT computers are in my office. Gilles
Marcel, I have tested your kdDebug() wrapper under my HT computer in my office and there is _NO_ crash (:=))) I have stressed the program to start more than on instance at the same time and let's running all during one hours : no problem... Note : with the previous test program, the crash appear just a few seconds after to start it. So, your implementation can be include in digiKam core, into /libs (put it in a new sub folder ?). This implementation need to be include in the shared library libdigikam.so because i will use it in DigikamImagePlugins. Gilles
Marcel, Just a little report. I have run your test program during this day under my 3 HT computers using ssh, and it doesn't crash... Gilles
Marcel, After investiguations, the better digiKam/DigikamImagePlugins common place to put your implementation is in the "libs/dimg/" folder. I recommend you to create a new class name DDebug (like Digikam Debug (:=))). Thanks in advance... Gilles
Created attachment 18463 [details] DDebug implementation This is the current patch. The idea is that using some #define magic (which I usually don't like at all, but I am pragmatic) and gcc's include option, the source does not need to be touched at all. Three Makefile.ams are changed so that the ddebug.h is included in all source files. This would have to be done with all other Makefile.ams. Alternatively, we can #include <ddebug.h> in every file, or even dont use the #define and replace every occurence of kdDebug with DDebug.
Thanks Marcel for this implementation. > Alternatively, we can #include <ddebug.h> in every file, or even dont use the > #define and replace every occurence of kdDebug with DDebug. I'm favorable to use this way intead a gcc macro witch can be an opaque solution. If we changing kdDebug with DDebug in source code we will be sure than we use it properly (:=))) I will add your source code in svn and looking changes requires in other place. Question : If i remplace all kdDebug() occurences in digiKam/DigikamImagePlugins, we will use DDebug in main thread too. I hope than this will not be a cause of any problems. Right ? Gilles
Marcel, I think that digiKam kio-slave implementation no need to be fixed using DDebug() because it running in separate process. Right for you ? Gilles
I already saw all your commits, so you did the tedious work ;-) #48: Not only can we use it in the main thread, we must use it in the main thread as well! If we used only kdDebug in the main thread, there could still be a race condition. We must replace every occurrence of kdDebug. #49: Yes, no need to use it in the ioslave. This is comment #50 for this bug. Time to celebrate ;-)
>We must replace every occurrence of kdDebug. Well it's done in digiKam and DigiKamImagePlugins (:=) Now, the problem is with kipi-plugins witch have some QThread parts. I wiill dupplicate your DDebug class into the common plugins area, change the namespace, and the name of the static mutex. I will use DDebug in all plugins witch use QThread, but i need to use it also in all others plugins ? Gilles
I think you do not need to use it in all (non-multithreaded) kipi-plugins. First, I think most plugins provide a modal dialog, so the host application is blocked anyway. If the host application is doing some multithreaded work while the plugin is running, that's a problem: using DDebug won't help, the mutex of the plugin will be different from the mutex of the host app, so you can with the same effect not use any mutex at all. That's a limitation of wrapping a common library function with a application-private mutex, the real solution (for the future) is to make kdDebug thread-safe.
> If the host application is doing some multithreaded work while the plugin is running, that's a problem: And it's possible because for example RAW converter dialog is non-modal. If you start digiKam camera interface during the RAW conversion there is a risk. A solution is to move DDBug into libkipi witch is common at all. right ? Gilles
Yes, that's a solution. Then the mutex is shared.
Angelo, Can you give us your viewpoint about DDebug integration in libkipi ? Gilles
Well, my point is that the fix should be done in kdDebug as said in comment #52. A temporary workaround is to add a common library somewhere with a thread safe implementation of kdDebug. If you think libkipi is the right place well, maybe it should be a "special" kdDebug extension that could add some helpful features, even if i don't know which ones :) Angelo
Angelo, Well after checking all kipi code, there is a few KDdebug() statements to fix in multithreaded implementation. I will use QDebug instead. like this libkipi is untouched. It's more simple until KdDebug() implementation support it. Gilles
is QDebug thread safe?
Angelo, qDebug() statement are used in Qt doc with QThread example. It must be thread-safe. But the syntax is more like printf(), not really C++ like kdDebug(). Gilles
> qDebug() statement are used in Qt doc with QThread example. It must be thread-safe. Right, I should read docs first, next time ;) > But the syntax is more like printf(), not really C++ like kdDebug(). That could be a problem, anyway. How can you be sure all the kipi's developer will use qDebug instead of kdDebug? I do believe kdDebug developers should be aware of the problem and provide a thread safe solution, if the attached patches could be useful for them they could use those ones, IMO. Another possible way could be having a "stringstream" for any threads in a map by thread id and sinchronize the access to the output every time an eot/eol/eof is coming (overload of overflow method). But I didn't think a lot to a real solution though... Angelo
Angelo, Only plugins using multi-threading implementation (QThread) with kdDebug() statements need to be fixed. All others parts can still use kdDebug() without problems. QThread is used in these kipi plugins : - RAW converter (I will fix it.). - Send Images (I have posted comments to new maintener about it). - JPEG LossLess (I will fix it.). - Find Images (???). - Kamera Klient (???). About KDEAPI, i'm agree with you than kdDebug() implementation need to be fix. But we cannot wit this fix to release digiKAm/DigikamImagePlugins/kipi-plugins... Also this want mean than we will depand of a future KDE version... Gilles
> About KDEAPI, i'm agree with you than kdDebug() implementation need to be fix. But we cannot wit this fix to release digiKAm/DigikamImagePlugins/kipi-plugins... Also this want mean than we will depand of a future KDE version... hmm, an important fix like that, should be backported in all the kde version supported
Right Angelo, But who contact for that ? Aaron Seigo ? Gilles
> But who contact for that ? Aaron Seigo ? Open a new bug to kdecore and let this bug depending on it?
or just CC Aaron in this file... Gilles
SVN commit 627622 by cgilles: kipi-plugins from trunk : libkexiv2 : do not use kdDebug() here because it's not thread-safe. Use qDebug() instead... CCBUGS: 133026 M +63 -139 libkexiv2.cpp M +1 -1 libkexiv2_export.h
SVN commit 816106 by dfaure: kDebug concurrency testing, based on code from bug 133026, by Marcel Wiesweg <marcel.wiesweg@gmx.de>. No problem in KDE4 (kDebug uses qDebug, and includes a mutex for protecting its own data). CCBUG: 133026 CCMAIL: "Gilles Caulier" <caulier.gilles@gmail.com> M +70 -4 kdebugtest.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=816106
Thanks David. Marcel, This is want mean than we can use KDE4::kDebug() everywhere... Gilles
\o/ Does that mean it is not deprecated any more? Angelo