duchain seems to be broken

Christoph Cullmann cullmann at babylon2k.de
Sun May 6 15:01:36 UTC 2007


On Sunday 06 May 2007 16:54:01 dukju ahn wrote:
> 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.
k, assert is away, as workaround, atm...
if you have better ideas for isSmartLocked(), feel free to patch it



-- 
Christoph Cullmann
KDE Developer, Kate Maintainer
http://babylon2k.de, cullmann at kde.org




More information about the KDevelop-devel mailing list