Fix for a race condition when starting language server - #1780
Open
analizator1 wants to merge 6 commits into
Open
analizator1 wants to merge 6 commits into
analizator1 wants to merge 6 commits into
Conversation
Member
|
@Mergifyio rebase |
1 similar comment
Member
|
@Mergifyio rebase |
Contributor
☑️ Command
|
Contributor
✅ Branch has been successfully rebased |
puremourning
force-pushed
the
fix_lsp_server_multiple_start
branch
from
December 16, 2025 22:36
6b6084a to
ebe9009
Compare
analizator1
force-pushed
the
fix_lsp_server_multiple_start
branch
from
July 2, 2026 23:32
ebe9009 to
34c0225
Compare
Contributor
☑️ Command
|
Contributor
🛑 The pull request rule doesn't match anymoreDetailsThis action has been cancelled. |
…) to complete This is a UT fixup for a change in _AwaitServerMessages. Note that ycm-core#1434 (comment) is not exactly correct together with ycm-core#1434. Quote: > (...) Note that the java completer has a ton of setup to do before it gets to the super().StartServer(). It's true that it has some additional tasks (wiping out workspace) before it calls *super()._StartServerNoLock()*. But PR 1434 doesn't address it - wiping workspace is called from JavaCompleter.StartServer() at which point _server_started is already True, so the following part from that PR in _AwaitServerMessages(): -return self._initialize_event.is_set() +return not self._server_started or self._initialize_event.is_set() did not make it return True. In other words, ycm-core#1434 seems to not address the JavaCompleter issue, but only the issue with potentially long extra conf Settings(). However according to ycm-core#1433 (comment) this should rather be solved by increasing MESSAGE_POLL_TIMEOUT. Anyway, one of the first things we do from OnFileReadyToParse() when server is not healthy is setting _server_started to True.
puremourning
force-pushed
the
fix_lsp_server_multiple_start
branch
from
July 2, 2026 23:33
34c0225 to
61d8b17
Compare
…nd was) multiplied by 3 Previous 15s (for semantic tokens) was too low for C++ and vim-ctrlspace when opening a workspace with 30+ cpp files. In this case YCM tries to request tokens for all buffers at once, causing large memory spike, possibly crashing clangd or OS. Snippet from clangd stderr after this change: Setting virtual memory limit for clangd to 14680064 KiB I[14:00:04.495] clangd version 22.1.6 (office-ic5-12:repos/ycm-llvm 08c722b5356d1ca19570b9d22f680cef1d8bbe48) I[14:00:04.497] Starting LSP over stdin/stdout I[14:00:04.500] <-- initialize(1) I[14:00:04.505] --> reply:initialize(1) 4 ms I[14:00:08.346] --> reply:textDocument/semanticTokens/full(6) 2378 ms I[14:00:09.814] --> reply:textDocument/semanticTokens/full(4) 4874 ms I[14:00:10.305] --> reply:textDocument/semanticTokens/full(5) 5163 ms I[14:00:12.653] --> reply:textDocument/semanticTokens/full(2) 8142 ms I[14:00:13.920] --> reply:textDocument/semanticTokens/full(10) 5942 ms I[14:00:15.515] --> reply:textDocument/semanticTokens/full(7) 8438 ms I[14:00:15.806] --> reply:textDocument/semanticTokens/full(8) 8513 ms I[14:00:17.271] --> reply:textDocument/semanticTokens/full(13) 8449 ms I[14:00:17.893] --> reply:textDocument/semanticTokens/full(3) 13052 ms I[14:00:19.226] --> reply:textDocument/semanticTokens/full(12) 10782 ms I[14:00:20.986] --> reply:textDocument/semanticTokens/full(24) 5844 ms I[14:00:21.374] --> reply:textDocument/semanticTokens/full(17) 9444 ms I[14:00:22.520] --> reply:textDocument/semanticTokens/full(29) 6308 ms I[14:00:26.170] --> reply:textDocument/semanticTokens/full(9) 18762 ms LLVM ERROR: out of memory LLVM ERROR: out of memory
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the following scenario:
What happens from time to time is that LSP server (in my case clangd) started more than once. With more than one running clangd process, YouCompleteMe does not work at all, because it tries to use a server that is not initialized - initialize request was sent to another one. Workaround: quit vim, kill ycmd and clangd processes, start vim again.
The way I fixed it is that
_server_startedis only accessed within_server_info_mutexand only the first thread callsStartServer(). Note that it required to partially revert #1434. Given that_server_startedis now accessed only within the mutex, it does not make any sense for_AwaitServerMessagesto access it. For additional rationale about it, see 6b6084a commit message.This change is