Did you try removing ~/.cache/kdevduchain and trying again?

Removed the cache (again). Now the crash is another (what I've observed first):

Thread 18 "Queue(0x1ebb850" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f1d07fff700 (LWP 15332)]
0x00007f1d8dfb9d25 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f1d8dfb9d25 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f1d8dfbb039 in __GI_abort () at abort.c:89
#2  0x00007f1d8dfb2fc7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7f1d1ee034b8 "DelayedTypos.empty() && \"Uncorrected typos!\"", 
    file=file@entry=0x7f1d1ee02e28 "/var/tmp/portage/sys-devel/clang-4.9999/work/clang-4.9999/lib/Sema/Sema.cpp", line=line@entry=317, function=function@entry=0x7f1d1ee09110 "clang::Sema::~Sema()") at assert.c:92
#3  0x00007f1d8dfb3072 in __GI___assert_fail (assertion=0x7f1d1ee034b8 "DelayedTypos.empty() && \"Uncorrected typos!\"", file=0x7f1d1ee02e28 "/var/tmp/portage/sys-devel/clang-4.9999/work/clang-4.9999/lib/Sema/Sema.cpp", 
    line=317, function=0x7f1d1ee09110 "clang::Sema::~Sema()") at assert.c:101
#4  0x00007f1d1e90d1d2 in clang::Sema::~Sema() () from /usr/lib64/../lib64/libclangSema.so.4
#5  0x00007f1d1f842156 in clang::ASTUnit::~ASTUnit() () from /usr/lib64/../lib64/libclangFrontend.so.4
#6  0x00007f1d1f842439 in clang::ASTUnit::~ASTUnit() () from /usr/lib64/../lib64/libclangFrontend.so.4
#7  0x00007f1d2476b55e in clang_disposeTranslationUnit () from /usr/lib64/libclang.so.4
#8  0x00007f1d24a95ebb in ParseSessionData::~ParseSessionData (this=0x7f1cfdd2b2f0, __in_chrg=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/duchain/parsesession.cpp:302
#9  0x00007f1d24a95ee9 in ParseSessionData::~ParseSessionData (this=0x7f1cfdd2b2f0, __in_chrg=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/duchain/parsesession.cpp:303
#10 0x00007f1d24cdc85b in ClangParseJob::run (this=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/clangparsejob.cpp:281
#11 0x00007f1d83a3e095 in ThreadWeaver::IdDecorator::run (this=<optimized out>, self=..., thread=0x7f1d000013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/iddecorator.cpp:69
#12 0x00007f1d83a3e5fe in ThreadWeaver::Executor::run (this=<optimized out>, job=..., thread=<optimized out>) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/executor.cpp:52
#13 0x00007f1d83a3d300 in ThreadWeaver::Job::execute (this=<optimized out>, self=..., th=0x7f1d000013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/job.cpp:83
#14 0x00007f1d83a3ce66 in ThreadWeaver::Thread::run (this=0x7f1d000013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/thread.cpp:114
#15 0x00007f1d8e7c35c4 in QThreadPrivate::start (arg=0x7f1d000013a0) at thread/qthread_unix.cpp:368
#16 0x00007f1d880063a4 in start_thread (arg=0x7f1d07fff700) at pthread_create.c:333
#17 0x00007f1d8e06bf0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I've noticed that the segfault happened with llvm/clang-4.0 branch. Before the bugreport I downgraded it to 3.9.1 but didn't realize that there were some leftovers kdevelop was still using. After cleaning up those leftovers and rebuilding kdevelop against llvm/clang-3.9.1 again, the crash doesn't happen anymore. So this may be a regression in llvm/clang.

Since llvm/clang-4.0 is released now, this problem becomes urgent. The background parser fails now with different projects. As far as I can see it's always the same assert:

[KCrash Handler]
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x00007ff2464e7f89 in __GI_abort () at abort.c:89
#8  0x00007ff2464dfd97 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7ff1c72a0070 "DelayedTypos.empty() && \"Uncorrected typos!\"", file=file@entry=0x7ff1c729f9e8 "/var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/lib/Sema/Sema.cpp", line=line@entry=316, function=function@entry=0x7ff1c72a5bf0 <clang::Sema::~Sema()::__PRETTY_FUNCTION__> "clang::Sema::~Sema()") at assert.c:92
#9  0x00007ff2464dfe42 in __GI___assert_fail (assertion=assertion@entry=0x7ff1c72a0070 "DelayedTypos.empty() && \"Uncorrected typos!\"", file=file@entry=0x7ff1c729f9e8 "/var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/lib/Sema/Sema.cpp", line=line@entry=316, function=function@entry=0x7ff1c72a5bf0 <clang::Sema::~Sema()::__PRETTY_FUNCTION__> "clang::Sema::~Sema()") at assert.c:101
#10 0x00007ff1c6d943a2 in clang::Sema::~Sema (this=0x7ff1a8082f10, __in_chrg=<optimized out>) at /var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/lib/Sema/Sema.cpp:316
#11 0x00007ff1c7cfa2ba in std::default_delete<clang::Sema>::operator() (this=<optimized out>, __ptr=0x7ff1a8082f10) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include/g++-v6/bits/unique_ptr.h:76
#12 std::unique_ptr<clang::Sema, std::default_delete<clang::Sema> >::~unique_ptr (this=0x7ff1a8009f08, __in_chrg=<optimized out>) at /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include/g++-v6/bits/unique_ptr.h:239
#13 clang::ASTUnit::~ASTUnit (this=0x7ff1a8009e40, __in_chrg=<optimized out>) at /var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/lib/Frontend/ASTUnit.cpp:235
#14 0x00007ff1c7cfa5b9 in clang::ASTUnit::~ASTUnit (this=0x7ff1a8009e40, __in_chrg=<optimized out>) at /var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/lib/Frontend/ASTUnit.cpp:260
#15 0x00007ff1d4bb828e in clang_disposeTranslationUnit (CTUnit=0x7ff1a800e890) at /var/tmp/portage/sys-devel/clang-9999/work/x/y/clang-9999/tools/libclang/CIndex.cpp:3908
#16 0x00007ff1d4ee214b in ParseSessionData::~ParseSessionData (this=0x7ff1a08f1980, __in_chrg=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/duchain/parsesession.cpp:313
#17 0x00007ff1d4ee2179 in ParseSessionData::~ParseSessionData (this=0x7ff1a08f1980, __in_chrg=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/duchain/parsesession.cpp:314
#18 0x00007ff1d512986b in ClangParseJob::run (this=<optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/languages/clang/clangparsejob.cpp:280
#19 0x00007ff23bd33085 in ThreadWeaver::IdDecorator::run (this=<optimized out>, self=..., thread=0x7ff1b00013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/iddecorator.cpp:69
#20 0x00007ff23bd335ee in ThreadWeaver::Executor::run (this=<optimized out>, job=..., thread=<optimized out>) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/executor.cpp:52
#21 0x00007ff23bd322f0 in ThreadWeaver::Job::execute (this=<optimized out>, self=..., th=0x7ff1b00013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/job.cpp:83
#22 0x00007ff23bd31e56 in ThreadWeaver::Thread::run (this=0x7ff1b00013a0) at /var/tmp/portage/kde-frameworks/threadweaver-9999/work/threadweaver-9999/src/thread.cpp:114
#23 0x00007ff246cf06a4 in QThreadPrivate::start (arg=0x7ff1b00013a0) at thread/qthread_unix.cpp:368
#24 0x00007ff240523394 in start_thread (arg=0x7ff1bec42700) at pthread_create.c:456
#25 0x00007ff246599abf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

This happens with llvm/clang-4.0 and latest devel versions.

two clang bugreports that seem related:

https://bugs.llvm.org//show_bug.cgi?id=22938
https://bugs.llvm.org//show_bug.cgi?id=21905

Still not sure if this is a clang-bug or kdevelop is miss-using something. At least something was changed during the 4.0-development cycle of clang, so this bug is triggered now.

Note: We don't recommend to build Clang/LLVM with assertions enabled. It triggers on a lot of issues in our experience, most of them non-fatal for us.

Do you get a crash with assertions disabled?

(In reply to Kevin Funk from comment #6)
> Note: We don't recommend to build Clang/LLVM with assertions enabled. It
> triggers on a lot of issues in our experience, most of them non-fatal for us.
> 
> Do you get a crash with assertions disabled?

Need to figure out how they are enabled/disabled with the Gentoo ebuild. I've not build llvm/clang with assertions enabled intentionally.

For the upstream build you need to pass -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF to cmake, fwiw

Sorry, forget my previous comment. LLVM_ENABLE_ASSERTIONS:BOOL is only useful for *enabling* assertions, it won't help for *disabling* them.

If you want to disable assertions you need -DCMAKE_BUILD_TYPE=RelWithDebInfo, or -DCMAKE_BUILD_TYPE=Release. Just *not* -DCMAKE_BUILD_TYPE=Debug.

(In reply to Kevin Funk from comment #9)
> Sorry, forget my previous comment. LLVM_ENABLE_ASSERTIONS:BOOL is only
> useful for *enabling* assertions, it won't help for *disabling* them.
> 
> If you want to disable assertions you need
> -DCMAKE_BUILD_TYPE=RelWithDebInfo, or -DCMAKE_BUILD_TYPE=Release. Just *not*
> -DCMAKE_BUILD_TYPE=Debug.

I've double checked this, assertions were disabled all the time. The assert that fires here is this one:

Sema::~Sema() {
  if (VisContext) FreeVisContext();
  // Kill all the active scopes.
  for (unsigned I = 1, E = FunctionScopes.size(); I != E; ++I)
    delete FunctionScopes[I];
  if (FunctionScopes.size() == 1)
    delete FunctionScopes[0];

  // Tell the SemaConsumer to forget about us; we're going out of scope.
  if (SemaConsumer *SC = dyn_cast<SemaConsumer>(&Consumer))
    SC->ForgetSema();

  // Detach from the external Sema source.
  if (ExternalSemaSource *ExternalSema
        = dyn_cast_or_null<ExternalSemaSource>(Context.getExternalSource()))
    ExternalSema->ForgetSema();

  // If Sema's ExternalSource is the multiplexer - we own it.
  if (isMultiplexExternalSource)
    delete ExternalSource;

  threadSafety::threadSafetyCleanup(ThreadSafetyDeclCache);

  // Destroys data sharing attributes stack for OpenMP
  DestroyDataSharingAttributesStack();

  assert(DelayedTypos.empty() && "Uncorrected typos!");
}

This is not guarded by NDEBUG and will trigger unconditionally. So again the question, is this a bug in clang/llvm or is kdevelop miss-using an interface?

assert() itself takes NDEBUG into account. In other words, if NDEBUG is defined when assert.h is included, assert() does nothing.

See: http://en.cppreference.com/w/c/error/assert

Sorry, one remark missing: if you use -DCMAKE_BUILD_TYPE=Release or ...=RelWithDebInfo, NDEBUG will be defined.

(In reply to Kevin Funk from comment #12)
> Sorry, one remark missing: if you use -DCMAKE_BUILD_TYPE=Release or
> ...=RelWithDebInfo, NDEBUG will be defined.

clang/llvm was build with -DCMAKE_BUILD_TYPE=RelWithDebInfo all the time. Will try with -DCMAKE_BUILD_TYPE=Release now.

RelWithDebInfo should be sufficient. But you also need to make sure that LLVM_ENABLE_ASSERTIONS:BOOL is not ON.

Please check whether your compiler invocations contain -DNDEBUG.

(In reply to Kevin Funk from comment #14)
> RelWithDebInfo should be sufficient. But you also need to make sure that
> LLVM_ENABLE_ASSERTIONS:BOOL is not ON.
> 
> Please check whether your compiler invocations contain -DNDEBUG.

-DCMAKE_BUILD_TYPE=RelWithDebInfo and -DCMAKE_BUILD_TYPE=Release  don't work. Setting -DNDEBUG via CFLAGS finally made it work (again). Either llvm/clang buildsystem is messed up or (more likely) the Gentoo-devs have broken something since 4.0-release.

Since kdevelop still works without the asserts, I'm closing this ticket again.