Clangd repeatedly exiting when using lsp in emacs on Windows


I recently started using lsp in emacs, which uses clangd for its C support. While developing I routinely get a message that Server clangd:<some number> has exited with status exit. Do you want to restart it? (y or n)

Sometimes it will be able to restart, other times it will fail. Even worse sometimes it will get into a loop where it seems to be trying to restart several clangd servers over and over, which continually fail to restart.

This seems to mostly happen when I open new files in my editor. Often it will occur when opening a new file and when I start to make my first edit.

I’ve checked the output of the lsp, but it doesn’t seem to indicate to me what the issue is. I usually just have to kill lsp, then reinitialize, but that only works for so long.

Let me know how I can go about diagnosing this or any info that would be useful.

Thank you!

I faced this problem with Clangd 7.0.0. I compiled clangd by gcc from source but the binary from LLVM it self was working correctly (it was build by Microsoft C++ compiler and is for windows). note that gcc (MinGW) is not 100% compatible with windows.

I suggest you to use LLVM installer if you built clangd from source. If not, your information is not sufficient to say something …

Same problems here, I compiled clangd version 11.0.0 from source, which exited with status code unexceptedly after emacs lsp recieved a initialize reply.

Error Log clangd version 11.0.0 compiled by me:

I[13:24:04.879] Starting LSP over stdin/stdout
I[13:24:04.880] <-- initialize(param in json format)
I[13:24:05.016] --> reply:initialize(param in json format) 135 ms
Process clangd stderr finished

Normal Log clangd 10.0.0 downloaded as binaries:

I[14:04:56.394] Starting LSP over stdin/stdout
I[14:04:56.395] <-- initialize(1)
I[14:04:56.402] --> reply:initialize(1) 7 ms
I[14:04:57.933] <-- initialized
1 Like

Seems really odd that there’s no more logs. (Stacktrace or error).

Can you try the binaries from here? Possible you’ve got a build with backtraces turned off

I’d also suggest adding -log=verbose and pasting the full log. If that doesn’t yield any clues, could you add -input-mirror-file=lsp_in.txt and attach the file?