ccls quits with RPC issues in Atom

[grondman]

Observed behavior

Using e3c1adc, I cannot get ccls to work properly in Atom (I did not try any other editor). If I open a C++ file, Atom simply gets back to me with

The C / C++ (ccls) language server has exited and exceeded the restart limit for project '/home/ivogrondman/test/'

Having a further look in the Atom logs, I can see that the error actually has to do with RPC:

C / C++ (ccls) rpc.onClose The RPC connection closed unexpectedly

If I build from commit 304f4d7, this behaviour does not occur!

Expected behavior

Perhaps too trivial to describe for this issue: ccls simply should not crash/stop.

Steps to reproduce

1. Build ccls using prebuilt LLVM/CLANG 8.0.0 binaries, as described in the Build section of the documentation.
2. Open Atom
3. Open .cpp file inside Atom.

System information

• ccls version (git describe --tags --long): 0.20181225.9-35-ge3c1adcf
• clang version: 8.0.0
• OS: Ubuntu 18.04
• Editor: Atom
• Language client (and version): ide-ccls 0.3.0

[wbthomason]

I think the issue with e3c1adc is broader than just Atom; I also get a crash using coc.nvim with that commit but not with 304f4d7.

I'm on Arch Linux using the ccls-git AUR package and identical coc.nvim config to that given in the wiki. My coc.nvim version is commit 0fa0af5. clang --version reports 7.0.1.

The specific crash I get is:

12:26:42 ccls             pipeline.cc:478 I loaded project. Refresh semantic highlight for all working file.
LLVMSymbolizer: error reading file: No such file or directory
#0 0x00007f53e2596b4b llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/libLLVM-7.so+0x900b4b)

#1 0x00007f53e2594fa4 llvm::sys::RunSignalHandlers() (/usr/lib/libLLVM-7.so+0x8fefa4)
#2 0x00007f53e259512e (/usr/lib/libLLVM-7.so+0x8ff12e)
#3 0x00007f53e1adc3c0 __restore_rt (/usr/lib/libpthread.so.0+0x123c0)
#4 0x0000560b74e2b969 (ccls+0x98969)
#5 0x00007f53e1ad1a9d start_thread (/usr/lib/libpthread.so.0+0x7a9d)
#6 0x00007f53e1a01b23 __GI___clone (/usr/lib/libc.so.6+0xfbb23)

Everything still works with commit 304f4d7.

[MaskRay]

e3c1adc was the faulty commit. I messed up the calling order of setVirtualFileSystem and createFilemanager. The correct sequence is below:

#if LLVM_VERSION_MAJOR >= 9 // rC357037
  Clang->createFileManager(FS);
#else
  Clang->setVirtualFileSystem(FS);
  Clang->createFileManager();
#endif

Fixed in HEAD.

[yhamdoud]

I think the issue with e3c1adc is broader than just Atom; I also get a crash using coc.nvim with that commit but not with 304f4d7.

I'm on Arch Linux using the ccls-git AUR package and identical coc.nvim config to that given in the wiki. My coc.nvim version is commit 0fa0af5. clang --version reports 7.0.1.

The specific crash I get is:

12:26:42 ccls             pipeline.cc:478 I loaded project. Refresh semantic highlight for all working file.
LLVMSymbolizer: error reading file: No such file or directory
#0 0x00007f53e2596b4b llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/libLLVM-7.so+0x900b4b)

#1 0x00007f53e2594fa4 llvm::sys::RunSignalHandlers() (/usr/lib/libLLVM-7.so+0x8fefa4)
#2 0x00007f53e259512e (/usr/lib/libLLVM-7.so+0x8ff12e)
#3 0x00007f53e1adc3c0 __restore_rt (/usr/lib/libpthread.so.0+0x123c0)
#4 0x0000560b74e2b969 (ccls+0x98969)
#5 0x00007f53e1ad1a9d start_thread (/usr/lib/libpthread.so.0+0x7a9d)
#6 0x00007f53e1a01b23 __GI___clone (/usr/lib/libc.so.6+0xfbb23)

Everything still works with commit 304f4d7.

@wbthomason
Arch just updated to clang 8. I'm now running into the same problem using a configuration identical to yours. Are you experiencing any issues as well?

[wbthomason]

@yhamdoud Afraid not :/

Have you rebuilt ccls since Clang updated?

[wbthomason]

@yhamdoud Actually, I may have spoken too soon. It looks like I am getting these crashes again.

[wbthomason]

@MaskRay Would you prefer we start a new issue? I'm having trouble getting an informative stack trace, but I'm not sure this is the same as #347

[MaskRay]

@wbthomason Yet if it is not #363 (comment)

[wbthomason]

I'm pretty sure the "new" issue here is #363, yeah.