[PATCH] make cmakeduchaintest run without asserts

[Aleix Pol]

Was this commited?

On Sun, May 24, 2009 at 5:23 PM, Peter Oberndorfer <kumbayo84 at arcor.de>wrote:

> On Sonntag 24 Mai 2009, David Nolden wrote:
> > Am Samstag 23 Mai 2009 23:18:05 schrieb Peter Oberndorfer:
> > > vm.insert CMAKE_CURRENT_SOURCE_DIR is needed since 953842
> > > where a Q_ASSERT was added to make sure CMAKE_CURRENT_SOURCE_DIR is
> defined
> > >
> > > addDocumentChain in testUses is needed to avoid assert indexed.data()
> ==
> > > context in removeDocumentChain that fires when a addDocumentChain was
> never
> > > called
> > >
> > > addDocumentChain + removeDocumentChain testDUChainWalk
> > > are needed to avoid assert m_recursiveImports.isEmpty()
> > > in TopDUContextLocalPrivate::clearImportedContextsRecursively
> > > ---
> > >
> > > I am no duchain/cmake expert, so please review carefully.
> > > Also i don't know if addDocumentChain + removeDocumentChain
> > > is the right cure for the m_recursiveImports.isEmpty() assert.
> > Your duchain fixes are correct. A top-context is only partially
> functional
> > when it was not added using addDocumentChain.
> >
> > Greetings, David
> >
> Good,
> while testing my changes for cmakeduchaintest i found another problem,
> which happend to me several times during shutdown of kdevelop after normal
> work.
> But it can be reproduced easier with this test.
>
> It manifests itself in a QMutex::lock: mutex lock failure
>
> KDevelop::shouldDoDUChainReferenceCountingInternal can access the mutex in
> the already destructed RefCountDecider.
> I also attached the part of the valgrind log.
>
> The attached test patch 1 makes this obvious by adding a assert.
> Attached test patch 2 "solves" this by never destructing RefCountDecider.
> You have another idea how to solve this properly?
> (My hack is prbably not thread safe)
>
> Greetings Peter
>
> ==24232==
> ==24232== Invalid read of size 1
> ==24232==    at 0x4088B7E: QMutex::lock() (qmutex.cpp:152)
> ==24232==    by 0x42E2318:
> KDevelop::shouldDoDUChainReferenceCountingInternal(void*)
> (referencecounting.cpp:57)
> ==24232==    by 0x4369C62: KDevelop::AppendedList<true,
> KDevelop::IndexedTypeIdentifier>::free(KDevelop::IndexedTypeIdentifier*)
> (appendedlist_static.h:94)
> ==24232==    by 0x437286E:
> KDevelop::IdentifierPrivate<true>::~IdentifierPrivate() (identifier.cpp:45)
> ==24232==    by 0x4363CDA: KDevelop::Identifier::~Identifier()
> (identifier.cpp:301)
> ==24232==    by 0x58DAE0B: __cxa_finalize (in /lib/libc-2.8.so)
> ==24232==    by 0x42BA2A8: ??? (in
> /home/kde-devel/kde/lib/libkdevplatformlanguage.so.1.0.0)
> ==24232==    by 0x44422B3: ??? (in
> /home/kde-devel/kde/lib/libkdevplatformlanguage.so.1.0.0)
> ==24232==    by 0x400E62D: _dl_fini (in /lib/ld-2.8.so)
> ==24232==    by 0x58DAB0B: exit (in /lib/libc-2.8.so)
> ==24232==    by 0x58C4613: (below main) (in /lib/libc-2.8.so)
> ==24232==  Address 0x6680920 is 0 bytes inside a block of size 96 free'd
> ==24232==    at 0x40235AC: operator delete(void*) (vg_replace_malloc.c:313)
> ==24232==    by 0x4088E24: QMutex::~QMutex() (qmutex.cpp:134)
> ==24232==    by 0x42E312E: RefCountDecider::~RefCountDecider()
> (referencecounting.cpp:37)
> ==24232==    by 0x58DAB0B: exit (in /lib/libc-2.8.so)
> ==24232==    by 0x58C4613: (below main) (in /lib/libc-2.8.so)
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090706/b4ed1941/attachment.html>