"Ycmd server killed" with newer ycmd

[ghost]

After upgrading ycmd to the (currently) latest revision 0bc9870, emacs-ycmd refuses to start with the generic "Ycmd server killed"/"Server timeout" messages.

This may be related to the ycmd revision ec4f335. Here's the log message for that revision:

commit ec4f335676351eb89e554d0c0b45f01e22243e1a
Merge: 2cfa4f58 bc258ddc
Author: Homu <homu@barosl.com>
Date:   Wed Jan 18 08:41:17 2017 +0900

    Auto merge of #601 - micbou:debug-info-dictionary, r=Valloric

    [READY][API] Return debugging information as a dictionary instead of a string

    Currently, the data returned by the `debug_info` handler is a block of text. This makes it difficult for clients to retrieve a specific information on the server (e.g. the path of the logfiles, the process identifier of a sub-server, etc.) or to customize the way it is displayed to the user.

    We improve this by returning a dictionary instead of a string. Its structure is fully explained in [the new `debug_info` API documentation](http://micbou.github.io/ycmd/#path--debug_info).

    There are two important changes on its content:
    - add information on the Python interpreter used to start the ycmd server: its path and its version.
    - move information on the `.ycm_extra_conf.py` file (its path and if it is loaded or not) from the Clang completer to ycmd itself since it is not supposed to be specific to this completer.

    This is obviously an API-breaking change but not a big one since it only affects the `debug_info` handler.

    @abingham @Qusic @LuckyGeck @mawww @richard1122

    <!-- Reviewable:start -->

    ---

    This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/ycmd/601)

    <!-- Reviewable:end -->

Downgrading ycmd to revision 96aabdc as a temporary solution works.

[ptrv]

Works for me. The ycmd commit you mention only affects the debug_info request, which is not used when starting the server.

What is the output in the *ycmd-server* window?

[ghost]

Empty, no ycmd processes running. I'll try to reproduce on a pure install (because I'm running spacemacs, and, well, you know, variables aplenty). Probably a misconfiguration (or a bug in a different component, it may have happened after a package update).

[abingham]

Yeah, I'd check *Messages* and, if possible, *ycmd-server* for clues. I'm on spacemacs as well, and sometimes dependencies get out of whack.

[ghost]

Yeah, I'd check *Messages* and, if possible, *ycmd-server* for clues.

There was nothing there to shed any light on the nature of the problem, alas. The only ycmd-related messages were "server timeout" and "server killed" in Messages.

Anyway, false alarm. I nuked elpa, reinstalled everything, and it started working again. I swear, doing this with spacemacs every other day is exhausting.

[ptrv]

I'm glad you could solve the issue. Happy completing!

[Congee]

Same issue here. ycmd-server just doesn't start. The server works well in vim. Not sure what's going wrong. I'm pretty surprised there is no exceptions printed for me to debug. Is this the elisp way to handle errors?

[mohkale]

Same problem. I tried nuking my ELPA directory, by simply trashing it and then waiting half an hour for spacemacs to reinstall all the packages, still doesn't work for me. I've reinstalled ycmd 6 times (normally that fixes it for a little while).

Whenever I run ycmd-open, the following three lines are printed to the messages buffer

Ycmd server killed
ERROR: Ycmd server timeout. If this happens regularly you may need to increase ‘ycmd-startup-timeout’.
Ycmd server is not running. Can’t send ‘semantic_completion_available’ request!

Edit:

I tried to sort out the issue. This command curl -LO 'https://raw.githubusercontent.com/ycm-core/ycmd/master/ycmd/default_settings.json' 2>/dev/null && py -3 '/path/to/ycmd/ycmd' --options_file default_settings.json will let you run ycmd outside of emacs and I found out that for me (on windows) it didn't even start up. I received a stacktrace ending with the message "OSError: [WinError 193] %1 is not a valid Win32 application". Exploring further, I found that libclang.dll was causing this error. I cleared and then reinstalled ycmd, that didn't help. Then I tried building ycmd with the --all flag and for now it's working. Initially I only enabled a handful of completers because I didn't need all of them. If anyones having any troubles, I suggest installing all of them.

Edit: Edit:

All things considered I would like to say a better error message would be appreciated here. Emacs simply telling me the server isn't running, doesn't help me to diagnose the problem at all. if the ycmd process dies almost immeadiately after starting (and before any request has been sent or responded to) maybe it'd be best to dump the processess stderr stream to the messages buffer.