Built kdevelop and kdevplatform at current 5.0 branch. Ran with 'gdb -ex run ~/kdevelop5/bin/kdevelop' and opened Skia, kdevelop, and kdevplatform projects (Skia one probably isn't a problem as currently KDevelop doesn't see any of its files since all the files are in sibling directories to the CMakeLIsts.txt). After a while (at about 10% complete) KDevelop segfaults with the following message Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc4d56700 (LWP 19575)] 0x00007fffced5800b in QVarLengthArray<unsigned int, 32>::append ( this=0x7ffff46efc10 <KDevelop::(anonymous namespace)::Q_QGS_temporaryHashTopDUContextDatam_problemsStatic::innerFunction()::holder+16>, t=@0x7fffc4d559b4: 58) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvarlengtharray.h:126 126 ptr[idx] = t; (gdb) bt #0 0x00007fffced5800b in QVarLengthArray<unsigned int, 32>::append ( this=0x7ffff46efc10 <KDevelop::(anonymous namespace)::Q_QGS_temporaryHashTopDUContextDatam_problemsStatic::innerFunction()::holder+16>, t=@0x7fffc4d559b4: 58) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qvarlengtharray.h:126 #1 0x00007fffced5785f in KDevelop::Stack<unsigned int, 32>::push ( this=0x7ffff46efc10 <KDevelop::(anonymous namespace)::Q_QGS_temporaryHashTopDUContextDatam_problemsStatic::innerFunction()::holder+16>, t=@0x7fffc4d559b4: 58) at $HOME/kdevelop5/include/kdevplatform/util/stack.h:60 #2 0x00007fffced66377 in KDevelop::TemporaryDataManager<KDevVarLengthArray<KDevelop::LocalIndexedProblem, 10>, true>::free ( this=0x7ffff46efc00 <KDevelop::(anonymous namespace)::Q_QGS_temporaryHashTopDUContextDatam_problemsStatic::innerFunction()::holder>, index=58) at $HOME/kdevelop5/include/kdevplatform/language/duchain/appendedlist.h:171 #3 0x00007fffced6520d in KDevelop::TopDUContextData::m_problemsFree (this=0x7fff84704f90) at $HOME/kdevelop5/include/kdevplatform/language/duchain/topducontextdata.h:78 #4 0x00007fffced65368 in KDevelop::TopDUContextData::m_problemsFreeChain (this=0x7fff84704f90) at $HOME/kdevelop5/include/kdevplatform/language/duchain/topducontextdata.h:78 #5 0x00007fffced653d0 in KDevelop::TopDUContextData::freeAppendedLists (this=0x7fff84704f90) at $HOME/kdevelop5/include/kdevplatform/language/duchain/topducontextdata.h:79 #6 0x00007fffced64d42 in KDevelop::TopDUContextData::~TopDUContextData (this=0x7fff84704f90, __in_chrg=<optimized out>) at $HOME/kdevelop5/include/kdevplatform/language/duchain/topducontextdata.h:61 #7 0x00007fffced69c5b in KDevelop::DUChainItemFactory<ClangDUContext<KDevelop::TopDUContext, 140>, KDevelop::TopDUContextData>::callDestructor (this=0x2d01ab0, data=0x7fff84704f90) at $HOME/kdevelop5/include/kdevplatform/language/duchain/duchainregister.h:70 #8 0x00007ffff3913bc2 in KDevelop::DUChainItemSystem::callDestructor ( this=0x7ffff48ecf20 <KDevelop::DUChainItemSystem::self()::system>, data=0x7fff84704f90) at ../language/duchain/duchainregister.cpp:45 #9 0x00007ffff38bf41e in KDevelop::DUChainBase::setData (this=0x7fff84761aa0, data=0x7fffc00031a8, constructorCalled=true) at ../language/duchain/duchainbase.cpp:85 #10 0x00007ffff389a7a5 in (anonymous namespace)::saveDUChainItem (data=..., item=..., totalDataOffset=@0x7fffc4d55bc4: 696, isSharedDataItem=false) at ../language/duchain/topducontextdynamicdata.cpp:86 #11 0x00007ffff389c38b in KDevelop::TopDUContextDynamicData::store (this=0x7fff84761d90) at ../language/duchain/topducontextdynamicdata.cpp:705 #12 0x00007ffff384110e in KDevelop::DUChainPrivate::doMoreCleanup ( this=0x7ffff40effe0 <KDevelop::(anonymous namespace)::Q_QGS_sdDUChainPrivate::innerFunction()::holder>, retries=1, needLockRepository=true) at ../language/duchain/duchain.cpp:746 #13 0x00007ffff383e2d6 in KDevelop::DUChainPrivate::CleanupThread::run (this=0x156afb0) at ../language/duchain/duchain.cpp:289 #14 0x00007ffff57f92be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x00007fffee9016aa in start_thread (arg=0x7fffc4d56700) at pthread_create.c:333 #16 0x00007ffff5111eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Reproducible: Always Steps to Reproduce: 1. Build recent 5.0 kdevelop and kdevplatform in debug on Ubuntu Wily. 2. Open kdevelop and kdevplatform projects. 3. Wait a bit. Actual Results: Crash. Expected Results: No crash. I did 'rm -rf ~/.cache/kdevduchain/' before running. This is with qtbase5 package at version 5.4.2+dfsg-2ubuntu9 . While there have been some issues with qvarlengtharray in the past, I don't see anything recent in the blame at https://github.com/qtproject/qtbase/blame/dev/src/corelib/tools/qvarlengtharray.h . The Skia project may or may not be relevant, I haven't been able to determine yet. The one thing it has which is unique is that it has a bunch of targets and sources, but none of the sources currently show up (become project items) because the CMakeLists.txt is generated and 'out of source' so all of the source paths look like '../../src/XXX.cpp'.
Not sure if it helps but I backed up to frame #2 above (appendedlist.h:171) and (gbd) list 171 m_freeIndicesWithData.push(index); (gdb) print threadSafe $17 = true print index $18 = 58 (gdb) print this->m_freeIndicesWithData $19 = {<QVarLengthArray<unsigned int, 32>> = {a = -173374208, s = 32768, ptr = 0x7ffff5aa8500 <QArrayData::shared_null>, { array = "[redacted]", q_for_alignment_1 = 0, q_for_alignment_2 = 0}}, <No data fields>} The 'a' and 's' here look a lot like garbage, so I can only assume m_freeIndicesWithData is in an invalid state at this point. If you have trouble reproducing, I can find out more if you can tell me what is interesting. Note that at frame #6 (gdb) print this->m_url.c_str() $12 = 0x7fff8466980b "/usr/include/x86_64-linux-gnu/sys/select.h" though this may or may not be relevant.
In the 5.0 branches, the KDevelop::Stack patch should have been reverted. It should only be used in master. Are you sure your build setup is sane and clean?
Hmmm... I thought I was, in that I ran 'ninja' and it re-ran cmake and then did 'ninja install' on both kdevplatfrom and kdevelop. However, after taking a closer look, it doesn't appear everything required to be rebuilt actually was. I deleted the install directory and the build directories and rebuilt from scratch. I'm no longer seeing this issue, so I think you're right here. I'll make this as resolved then. Thanks for pointing out that this wasn't possible in 5.0.
I've encountered the same bug in ninja or the CMake ninja generator myself a few months ago and switched back to make... thanks for the confirmation