lsp-mode hangs when parsing system headers

[johngavingraham]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

Sometimes, LPS keep hanging while parsing headers when I'm dealing with C++ code. This leaves me unable to interact and I have to C-g to interrupt it, but then it starts again.

This issue has persisted for quite a while, and I do an auto-package-update every week, I've tried quite a lot to fix it.

It will say it's parsing some headers, and keep saying it's connected to clangd. It will then get stuck on one header - I can leave it for a few minutes and it hasn't moved on. Then I need to C-g to interrupt it and carry on, though it leaves buffers open (e.g. to a system header that it was parsing) and I find I need to shut them down before I can get on with using emacs, as otherwise a few seconds later it will get back on with parsing the header and get stuck again.

An example of this from *Messages*, just now:

Parsing fold_left.hpp (LL)...done
LSP :: Opening read-only library file /usr/include/boost/preprocessor/list/detail/fold_right.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
Parsing fold_right.hpp (LL)...done
LSP :: Opening read-only library file /usr/include/boost/type_traits/is_union.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/sp_has_gcc_intrinsics.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/sp_has_sync_intrinsics.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/atomic_count_std_atomic.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/atomic_count_gcc.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/atomic_count_nt.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/bad_weak_ptr.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/sp_counted_base.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
Parsing sp_counted_impl.hpp (LL)...done
LSP :: Opening read-only library file /usr/include/boost/core/checked_delete.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/assert/source_location.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].
LSP :: Opening read-only library file /usr/include/boost/exception/exception.hpp.
LSP :: Connected to [clangd:9470 /home/john/src/cpprito].

Steps to reproduce

I edit any C++ file - sometimes this will happen, some times it won't. It seems to be worse if I have system headers open, e.g. if I've just gone to a bunch of definitions.

Expected behavior

The headers get parsed in a reasonable time.

Which Language Server did you use?

I'm not entirely sure what this means. I have (use-package lsp-mode) and (add-hook 'c++-mode-hook 'lsp) in my emacs config, and it connects to clangd.

OS

Linux

Error callstack

No response

Anything else?

In addition to the above from *Messages*, there's lots of this that seems to indicate it keeps reconnecting to clangd, from *lsp-log*:

Command "clangd --header-insertion-decorators=0" is present on the path.
Command "semgrep lsp" is not present on the path.
Command "clangd --header-insertion-decorators=0" is present on the path.
Command "semgrep lsp" is not present on the path.
Command "clangd --header-insertion-decorators=0" is present on the path.
Command "semgrep lsp" is not present on the path.

[johngavingraham]

I know this is a vague issue, but I really don't know how to proceed or find out the cause, I'm willing to investigate if given some direction though.

As things stand, it seems that whenever I type a non-trivial (i.e. not in my project) namespace, something hangs and I have to C-g out of it. If I don't it might take anywhere from ~5s to more than several minutes for emacs to become responsive again, and it's making emacs unusable.

Nothing like this happens when I'm editing python or rust, for which I've used emacs as a daily driver for a while now, but I've only just come back to C++ after a long time away.

As an aside, lsp-doctor results:

Checking for Native JSON support: OK
Check emacs supports `read-process-output-max': OK
Check `read-process-output-max' default has been changed from 4k: OK
Byte compiled against Native JSON (recompile lsp-mode if failing when Native JSON available): OK
`gc-cons-threshold' increased?: OK
Using `plist' for deserialized objects? (refer to https://emacs-lsp.github.io/lsp-mode/page/performance/#use-plists-for-deserialization): OPTIONAL
Using emacs 28+ with native compilation?: OPTIONAL

[psibi]

I know this is a vague issue, but I really don't know how to proceed or find out the cause, I'm willing to investigate if given some direction though.

When such a issue happens, I try to use another editor (typically Visual Studio) and see how it behaves. If it also hangs, then it's likely an issue with LSP server. If not, I would compare the lsp logs of both visual studio and Emacs and see what's the difference between each of them to figure out the bug.

[johngavingraham]

Closed as opened a more specific one: #4563