duchain seems to be broken

dukju ahn dukjuahn at gmail.com
Sun May 6 14:54:01 UTC 2007


2007/5/6, Christoph Cullmann <cullmann at babylon2k.de>:
> On Sunday 06 May 2007 15:54:56 Andreas Pakulat wrote:
> > On 06.05.07 09:16:47, dukju ahn wrote:
> > > 2007/5/5, Jakob Petsovits <jpetso at gmx.at>:
> > > > Ah right. This was the crash I asked you about (which did not happen on
> > > > your system at that time), approximately two weeks ago.
> > > >
> > > > It's caused by a QMutexLocker which does not lock even if it really
> > > > should, in lib/editor/editorintegrator.cpp:190 and the following lines:
> > > >
> > > > Range* newRange = data()->topRanges[currentUrl()][type] =
> > > >         createRange(currentDocument()->documentRange());
> > > > if (SmartInterface* iface = smart()) {
> > > >     QMutexLocker lock(iface->smartMutex());
> > > >     Q_ASSERT(newRange->isSmartRange());
> > > >     iface->addHighlightToDocument( newRange->toSmartRange(), false );
> > > >     newRange->toSmartRange()->addWatcher(data());
> > > > }
> > > >
> > > > The line
> > > >     iface->addHighlightToDocument( newRange->toSmartRange(), false );
> > > > crashes, because the QMutexLocker two lines above DOES NOT LOCK the
> > > > mutex. Check it for yourself by adding the debug lines
> > > >
> > > > bool smartLocked = true;
> > > > if (iface->smartMutex()->tryLock()) {
> > > >     iface->smartMutex()->unlock();
> > > >     smartLocked = false;
> > > > }
> > > >
> > > > directly after the QMutexLocker creation.
> > > > (That's the code that Katepart uses to check if the mutex is locked.)
> > >
> > > I've found the reason of error. The reason was the kdelibs/ktexteditor
> > > The smartMutex is initialized with QMutex::Recursive mode. In case of
> > > recursive mutex, one single thread can gain a lock again and again.
> > > So in above code, the tryLock() can always gain a lock, and the return
> > > value was false.
> > >
> > > In short, the assert code which ktexteditor used was a bug. Only after
> > > the mutex was initted with Non-Recursive more, or we change the
> > > Q_ASSERT code in kdelibs, the error cannot be solved.
> >
> > I'm forwarding this to kwrite-devel as obviously there's something wrong
> > in katepart.
> Hmm, the assert looks ok for me, but no expert in this area, Hamish has

Yes the assert macro seems fine. But
The problem is " bool KateDocument::isSmartLocked() const ", which is
used by the assert macro. Because isSmartLocked() returns false even
though the mutex was correctly locked, the assertion failed. And the
reason why isSmartLocked() returns false is because it uses tryLock()
Just see  KateDocument::isSmartLocked()

Of course, to be clear, I ran inside debugger and verified that
QMutex::lock() successful locked the startMutex.




More information about the KDevelop-devel mailing list