The ycmd server SHUT DOWN

[wixman]

getting this error on my work computer as soon as I open vim - when I restart it says "('Connection aborted.', error(111, 'Connection refused'))"

no idea where to start - any suggestions?

[Alex Merritt]

I get this too and tried updating to the latest. YcmDiags says

Forcing compilation, this will block Vim until done.
The ycmd server SHUT DOWN (restart with :YcmRestartServer).  check console output for logs!

('Connection aborted.', error(111, 'Connection refused'))

No warnings or errors detected
Press ENTER or type command to continue

I do not see any process named ycmd executing, so it is possible the process never started, or died at some point. That would explain the connection refused (since nothing is listening).

YcmDebugInfo says

Printing YouCompleteMe debug information...
-- Server crashed, no debug info from server
-- Server running at: http://127.0.0.1:40063
-- Server process ID: 12103

but there is no process ID 12103 when I check.

I've actually had the connection between vim and ycmd break over time, forcing me to YcmRestartServer and end up with many ycmd processes on my system. But this may be a separate issue altogether.

What could likely cause ycmd to hiccup before vim can make a connection?

-Alex

[Alex Merritt]

Here's more information.

I am using RHEL 6.5 and have gcc (GCC) 4.4.7 and clang version 3.4.2. These are quite old. I installed gcc 4.8 from source and compiled YCM using these:

CC=gcc-4.8 CXX=g++-4.8 CXXFLAGS="-std=c++11" ./install.sh --clang-completer

My theory is the ycmd server isn't starting at all because of an error with the dynamic linker. Here's why I suspect this:

$ cd ~/.vim/bundle/YouCompleteMe/third_party/ycmd

$ ldd ycm_core.so

./ycm_core.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/foo/.vim/bundle/YouCompleteMe/third_party/ycmd/./libclang.so)

./ycm_core.so: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /home/foo/.vim/bundle/YouCompleteMe/third_party/ycmd/./libclang.so)

        linux-vdso.so.1 =>  (0x00007fffeadff000)

        libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f114b60d000)

        libclang.so => /home/foo/.vim/bundle/YouCompleteMe/third_party/ycmd/./libclang.so (0x00007f114a72f000)

        librt.so.1 => /lib64/librt.so.1 (0x00007f114a527000)

        libstdc++.so.6 => /opt/local/lib64/libstdc++.so.6 (0x00007f114a21e000)

        libm.so.6 => /lib64/libm.so.6 (0x00007f1149f99000)

        libgcc_s.so.1 => /opt/local/lib64/libgcc_s.so.1 (0x00007f1149d83000)

        libc.so.6 => /lib64/libc.so.6 (0x00007f11499ef000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f11497d1000)

        libdl.so.2 => /lib64/libdl.so.2 (0x00007f11495cd000)

        libutil.so.1 => /lib64/libutil.so.1 (0x00007f11493ca000)

        /lib64/ld-linux-x86-64.so.2 (0x000000383d200000)

Some may claim this as an "environment problem, not a YCMD issue" but I don't think this helps anyone.

1. Is YCMD being built by linking against something it should not be?
2. Should the order of paths given to the dynamic linker be adjusted to point it to the correct libc so it finds that one first when loading these libraries?

Thanks.

[Alex Merritt]

May have to try this:

https://github.com/Valloric/YouCompleteMe#i-get-glibc_2xx-not-found-required-by-libclangso-when-starting-vim

It would seem RHEL 6.5 is "too old" for the libraries and requires a new clang and manual build of YCM.

[Ben Jackson]

Yes I had to build clang from source on rhel 6.5 using dev toolset 2. And installed it in some root like /opt/clang

I never used install.sh, just used cmake directly to give it the path to my clang install.