[Digikam-devel] [Bug 133026] New: crashes on systems using hyperthreading

[Gerhard Kulzer]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From gerhard kulzer net  2006-08-30 20:36 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

El Miércoles, 30 de Agosto de 2006 20:36, Gerhard Kulzer escribió:

> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=133026
>
>
>
>
> ------- Additional Comments From gerhard kulzer net  2006-08-30 20:36
> ------- 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
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

I'm using an AMD Dual Core 64 bits, with 2.6.15-26-amd64-generic #1 SMP
PREEMPT kernel and I've been testing digikam intensenly converting RAW files
to 32 bits png images and editing these ones, using some of the image plugins
like refocus and color related stuff and no crash has happened. At this
moment digiKam shows itself as solid as astable version.

In anyway, I'll keep on testing it.

Paco.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From fj.cruz supercable es  2006-08-30 22:13 -------
El Mi�rcoles, 30 de Agosto de 2006 20:36, Gerhard Kulzer escribi�:
[bugs.kde.org quoted mail]

I'm using an AMD Dual Core 64 bits, with 2.6.15-26-amd64-generic #1 SMP
PREEMPT kernel and I've been testing digikam intensenly converting RAW files
to 32 bits png images and editing these ones, using some of the image plugins
like refocus and color related stuff and no crash has happened. At this
moment digiKam shows itself as solid as astable version.

In anyway, I'll keep on testing it.

Paco.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From caulier.gilles free fr  2006-08-31 18:24 -------
Antonio,

You said that all work fine for you. Witch kernel and glibc release you use on your 32 bits HT computer ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From caulier.gilles free fr  2006-08-31 18:28 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From aumuell reserv at  2006-08-31 21:39 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From aironmail gmail com  2006-09-13 10:10 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From aironmail gmail com  2006-09-14 20:56 -------
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 ?? ()
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From aironmail gmail com  2006-09-14 22:55 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From marcel.wiesweg gmx de  2006-09-15 12:21 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From caulier.gilles free fr  2006-10-26 08:29 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- 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 :

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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From marcel.wiesweg gmx de  2006-10-26 21:58 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerhard Kulzer]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From gerhard kulzer net  2006-10-27 08:55 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From aironmail gmail com  2006-10-28 00:55 -------
I've tried it and it didn't crash in my tests, so I think that the problem is fixed. Great work!
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From caulier.gilles kdemail net  2006-10-28 11:10 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From marcel.wiesweg gmx de  2006-10-28 17:04 -------
Created an attachment (id=18303)
 --> (http://bugs.kde.org/attachment.cgi?id=18303&action=view)
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From maksim kde org  2006-10-28 17:06 -------
(sigh). People, kdelibs are not threadsafe, and are not claimed to be threadsafe anywhere.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From caulier.gilles kdemail net  2006-10-28 17:17 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Heiner Lamprecht]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=133026         




------- Additional Comments From heiner heiner-lamprecht net  2006-10-30 10:53 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel