Segfault on code completion in malformed code.

[lixiaolan]

Describe the bug
Code complete at causes segfault when code is malformed. In this particular example, I define a constructor both in the header file and in the object code.

To Reproduce

Create 3 files as following in some folder:

game.cpp

#include "game.h"

Game::Game(int size) : size{size} {
    
};

game.h

class Game {
public:
    Game(int size) : size{size} {};
    
private:
    int size;
};

makefile

game: game.cpp game.h
	g++ -c -std=c++11 game.cpp game.h

Now generate the compile commands. I ran bear make to get the
following:

[
    {
        "command": "c++ -c -std=c++11 game.h /home/user/tmp/bug_test/game.cpp",
        "directory": "/home/user/tmp/bug_test",
        "file": "/home/user/tmp/bug_test/game.cpp"
    }
]

Note: running make results in errors because the code is wrong (both
.cpp and .h define the constructor implementation). Even so, bear make happily generates compile commands.

Now run rtags and load the commands:

rdm -C &
rc -J compile_commands.json

Finally, try running any code completion inside of .cpp files. E.g:

/usr/local/bin/rc --code-complete-at /home/user/tmp/bug_test/game.cpp:4:5: --code-complete-prefix=adsf

At this point rdm crashes with the following trace:

Caught signal 11
rdm[0x45c2c0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fdd29651390]
/usr/lib/llvm-3.8/lib/libclang-3.8.so.1(+0xa03ecc)[0x7fdd2a260ecc]
/usr/lib/llvm-3.8/lib/libclang-3.8.so.1(+0x36e4d0)[0x7fdd29bcb4d0]
/usr/lib/llvm-3.8/lib/libclang-3.8.so.1(+0x36f149)[0x7fdd29bcc149]
/usr/lib/llvm-3.8/lib/libclang-3.8.so.1(+0x36f4b5)[0x7fdd29bcc4b5]
/usr/lib/llvm-3.8/lib/libclang-3.8.so.1(clang_getFileLocation+0x26a)[0x7fdd29a0cf1a]
rdm(_ZN5RTags19DiagnosticsProvider8diagnoseEv+0x2eb)[0x46f19b]
rdm(_ZN16CompletionThread18processDiagnosticsEPKNS_7RequestEP21CXCodeCompleteResultsP21CXTranslationUnitImpl+0x64e)[0x50796e]
rdm(_ZN16CompletionThread7processEPNS_7RequestE+0x29f7)[0x50ddb7]
rdm(_ZN16CompletionThread3runEv+0x139)[0x50fa09]
rdm(_ZN6Thread10localStartEPv+0x25)[0x5d78b5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7fdd296476ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fdd286ba41d]

[1]+  Exit 1                  rdm -C

Expected behavior
I would expect (in general) that rdm not segfault.

Note: The above example is a greatly simplified scenario. I came across this bug while working on a project and narrowed it down to this minimal example in order to help clarify the problem. So, though it might seem pathological, this was and is a real issue :)

Screenshots/Backtrace
(backtrace is printed above)

Environment:

OS/Version

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

rtags version

$ rdm --version
2.38.131
$ rc --version
2.38.131

Emacs version

(not needed since it isn't used for this bug)

llvm/clang

$ clang --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Note: Please let me know if I can provide any further information to help get to the bottom of this. I did notice that this may be related to another bug filed previously: #1363. I can't tell if this is the same problem or not so I filed a separate bug. In any case, both are worth a look. I am very interested in improving the stability of rtags as I am a fan of the functionality but concerned about the crashes :)

[lixiaolan]

I was able to 'fix' this issue. After running rdm in gdb and checking the back-trace it appeared the exception was triggered in clang/llvm rather than rtags proper. I then installed a newer version of clang/llvm (6.0 for what it's worth) and re-installed rtags with the new version. This has resolved the issue for me. Technically there is still some kind of bug present when using rtags with clang/llvm version 3.8 so maybe this can stay open for visibility.

Hope it helps :)