Bug 2151288

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.