Nathan Ridge
Nathan Ridge
One challenge with implementing this is that the URLs at which the version-specific links are posted don't seem to be very predictable. Looking at the links in https://releases.llvm.org/, for the...
Does this log cover the time when the crash occurred? I'm not seeing anything related to the crash, such as a backtrace, or evidence of clangd restarting, in it.
Also, just as an aside: ``` I[03:49:52.713] argv[0]: /home/book/.vscode-server/data/User/globalStorage/llvm-vs-code-extensions.vscode-clangd/install/18.1.3/clangd_18.1.3/bin/clangd I[03:49:52.713] argv[1]: --compile-commands-dir=/home/book/00_linux/05_sr04/build/ I[03:49:52.713] argv[2]: --query-driver=/home/book/100ask_imx6ull-sdk/ToolChain/arm-buildroot-linux-gnueabihf_sdk-buildroot/bin/arm-buildroot-linux-gnueabihf-g++ I[03:49:52.713] argv[3]: --header-insertion=never I[03:49:52.713] argv[4]: --clang-tidy I[03:49:52.713] argv[5]: --background-index I[03:49:52.713] argv[6]: --completion-style=detailed I[03:49:52.713] argv[7]: --compile-commands-dir=/home/book/00_linux/05_sr04/build/...
Maybe it's a hang rather than a crash? Can you attach a debugger to the clangd process and get a stack trace to see where it's hanging?
I would consider clangd getting into a deadlock on any input (source code) to be a bug. If you are able to share a code example that reproduces the problem...
Thank you for sharing reproduction steps. However since we're talking about a non-trivial project with toolchain dependencies and such, it would be good to try some quicker diagnostic steps first,...
1. When the hang occurs, run `top` and take note of the PID of the hanging clangd process. 2. Run `gdb attach ` in a terminal 3. Run `thread apply...
I think you may have attached to the vscode process rather than the clangd process, because I'm seeing things related to `node` in those backtraces (and nothing related to clangd).
Yeah, the first number printed by `ps` (at least with these flags) is the PID of the process's parent, and the second number is the process's own PID. This explains...
> Since the last time, it seems that clangd hasn't been consuming a lot of CPU, but it's still not working. Could you clarify please the way in which it's...