Description of problem: When editing C++ code in Qt Creator, clangd frequently crashes with SIGABRT. Version-Release number of selected component (if applicable): clang-tools-extra-15.0.4-1.fc37.x86_64 qt-creator-0:8.0.1-5.fc37.x86_64 How reproducible: I wasn't able to find minimal reproducible example, but it happens often enough (once a day at least).
Created attachment 1930493 [details] crash log
Here is another stack trace from gdb (from crash dump): #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f8f290afee3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f8f2905faa6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f8f29049886 in __GI_abort () at abort.c:100 #4 0x00007f8f292d7e80 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at ../../../../../libstdc++-v3/src/c++11/debug.cc:60 #5 0x00007f8f32e0bc7c in clang::syntax::TokenBuffer::spelledForExpandedToken (this=0x7f8ef9648b50, Expanded=<optimized out>) at /usr/src/debug/clang-15.0.4-1.fc37.x86_64/lib/Tooling/Syntax/Tokens.cpp:357 #6 0x00007f8f32e0c313 in clang::syntax::TokenBuffer::spelledForExpanded (this=0x7f8ef9648b50, Expanded=...) at /usr/src/debug/clang-15.0.4-1.fc37.x86_64/lib/Tooling/Syntax/Tokens.cpp:466 #7 0x0000560b2b3118db in clang::clangd::(anonymous namespace)::DumpVisitor::TraverseDecl(clang::Decl*) () #8 0x0000560b2b3178ab in clang::RecursiveASTVisitor<clang::clangd::(anonymous namespace)::DumpVisitor>::TraverseNamespaceDecl(clang::NamespaceDecl*) () #9 0x0000560b2b311efb in clang::clangd::(anonymous namespace)::DumpVisitor::TraverseDecl(clang::Decl*) () #10 0x0000560b2b320698 in clang::RecursiveASTVisitor<clang::clangd::(anonymous namespace)::DumpVisitor>::TraverseTranslationUnitDecl(clang::TranslationUnitDecl*) () #11 0x0000560b2b311dfb in clang::clangd::(anonymous namespace)::DumpVisitor::TraverseDecl(clang::Decl*) () #12 0x0000560b2b310ed3 in clang::clangd::dumpAST(clang::DynTypedNode const&, clang::syntax::TokenBuffer const&, clang::ASTContext const&) () #13 0x0000560b2b2cc1bb in void llvm::detail::UniqueFunctionBase<void, llvm::Expected<clang::clangd::InputsAndAST> >::CallImpl<clang::clangd::ClangdServer::getAST(llvm::StringRef, llvm::Optional<clang::clangd::Range>, llvm::unique_function<void (llvm::Expected<llvm::Optional<clang::clangd::ASTNode> >)>)::$_34>(void*, llvm::Expected<clang::clangd::InputsAndAST>&) () #14 0x0000560b2b4c5443 in void llvm::detail::UniqueFunctionBase<void>::CallImpl<clang::clangd::(anonymous namespace)::ASTWorker::runWithAST(llvm::StringRef, llvm::unique_function<void (llvm::Expected<clang::clangd::InputsAndAST>)>, clang::clangd::TUScheduler::ASTActionInvalidation)::$_8>(void*) () #15 0x0000560b2b4bb375 in clang::clangd::(anonymous namespace)::ASTWorker::runTask(llvm::StringRef, llvm::function_ref<void ()>) () #16 0x0000560b2b4bae41 in void llvm::detail::UniqueFunctionBase<void>::CallImpl<clang::clangd::(anonymous namespace)::ASTWorker::create(llvm::StringRef, clang::clangd::GlobalCompilationDatabase const&, clang::clangd::TUScheduler::ASTCache&, clang::clangd::TUScheduler::HeaderIncluderCache&, clang::clangd::AsyncTaskRunner*, clang::clangd::Semaphore&, clang::clangd::TUScheduler::Options const&, clang::clangd::ParsingCallbacks&)::$_5>(void*) () #17 0x0000560b2b64b54e in void* llvm::thread::ThreadProxy<std::tuple<clang::clangd::AsyncTaskRunner::runAsync(llvm::Twine const&, llvm::unique_function<void ()>)::$_4> >(void*) () #18 0x00007f8f290ae14d in start_thread (arg=<optimized out>) at pthread_create.c:442 #19 0x00007f8f2912fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 This crash happened when I tried to comment something out inside function parameter list, like this: configuration.serverUrl.setPath(/*server.apiPath*/)
BTW similar crashes happened to me on Fedora 36 too, with LLVM 14.
Following code causes it to enter endless crash loop: "#if QT_VERSION_CHECK()"
*** Bug 2238170 has been marked as a duplicate of this bug. ***
This happens sporadically when using QtCreator to edit C++ files with clangd enabled. I can't easily construct a minimal example that triggers, but it usually happens when I'm in the middle of typing a statement and clangd is used to fetch a code suggestion. It happens several times a day. reporter: libreport-2.17.11 crash_function: std::__glibcxx_assert_fail dso_list: /usr/bin/clangd clang-tools-extra-16.0.6-3.fc38.x86_64 (Fedora Project) 1694712001 rootdir: / type: CCpp kernel: 6.5.8-200.fc38.x86_64 journald_cursor: s=710b1614b4814135a4278328f6279e0f;i=109c0d5;b=44bd82caf90a4e6cac9a4f38d5fccd3a;m=c6e56d68;t=608ff15b0f967;x=96c31a43f7912690 executable: /usr/bin/clangd package: clang-tools-extra-16.0.6-3.fc38 cgroup: 0::/user.slice/user-1000.slice/session-2.scope cmdline: /usr/bin/clangd --background-index --header-insertion=never --limit-results=100 --limit-references=0 --clang-tidy=0 --background-index-priority=low --rename-file-limit=0 --compile-commands-dir=/home/matthew/work/ablacon/git/navlite-fim/build-components-Desktop-Debug/.qtc_clangd --use-dirty-headers backtrace_rating: 4 reason: clangd killed by SIGABRT runlevel: N 5 uid: 1000
Created attachment 1996349 [details] File: backtrace
From what I understand, clangd should be more stable in Fedora 39. Would you be able to test on Fedora 39?
This happens occassionally when using QtCreator (12.0.0, but also happened on 11) to edit C++ files. There's no particular sequence of events that I can discern. It happens most frequently when switching branches with git, and hence there are a lot of new files to reindex using clangd. reporter: libreport-2.17.11 crash_function: std::__glibcxx_assert_fail dso_list: /usr/bin/clangd clang-tools-extra-16.0.6-3.fc38.x86_64 (Fedora Project) 1694712001 rootdir: / type: CCpp kernel: 6.5.10-200.fc38.x86_64 journald_cursor: s=710b1614b4814135a4278328f6279e0f;i=10c0916;b=260671dcb3bd4d0cb01ab95d2e29d88a;m=1943cee57;t=60a91bf17b203;x=77aca1cba83339e9 executable: /usr/bin/clangd package: clang-tools-extra-16.0.6-3.fc38 cgroup: 0::/user.slice/user-1000.slice/session-2.scope cmdline: /usr/bin/clangd --background-index --header-insertion=never --limit-results=100 --limit-references=0 --clang-tidy=0 --background-index-priority=low --rename-file-limit=0 --compile-commands-dir=/home/matthew/work/ablacon/git/navlite-fim/build-components-Desktop-Debug/.qtc_clangd --use-dirty-headers backtrace_rating: 4 reason: clangd killed by SIGABRT runlevel: N 5 comment: This happens occassionally when using QtCreator (12.0.0, but also happened on 11) to edit C++ files. There's no particular sequence of events that I can discern. It happens most frequently when switching branches with git, and hence there are a lot of new files to reindex using clangd. uid: 1000
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.