Summary: | KDevelop crash during background parsing code: assertion=assertion@entry=0x7ff1c72a0070 "DelayedTypos.empty() && \"Uncorrected typos!\"", file=file@entry=0x7ff1c729f9e8 | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Johannes Hirte <johannes.hirte> |
Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | heri+kde, mail, univerz |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Johannes Hirte
2017-02-07 17:00:31 UTC
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. |