libclang crash - Githubissues

sebastiencs commented 7 years ago

I have a project where I included QtWebChannel and I had very often crashes with libclang. The messages in the Messages buffer are:

error in process filter: irony--process-server-response: End of file during parsing
error in process filter: End of file during parsing

I was able to reproduce the crash with this simple case:

#include <QtWebChannel/QtWebChannel>
#include <iostream>
#include <string>

int     main(int ac, char **av) {
  QWebChannel monChannel;

  std::string str;

  str = "coucou";

  monChannel.blockUpdates();
  mon|

}

With this case it crashes almost always, if it doesn't I restart emacs. My cursor is at the pipe place. At this point, I'm waiting 2-3 seconds (until flycheck signal me that there is a problem) and I execute 'company-complete'. Then I receive the error message.

There is the irony.log:

execute: Command{action=Command::Parse, file='/tmp/fail/main.cpp', dir='', line=0, column=0, flags=['-x', 'c++', '-working-directory', '/tmp/fail/', '-std=c++14', '-I/opt/Qt/5.7/gcc_64/include'], unsavedFiles.count=1, opt=off}
execute: Command{action=Command::Diagnostics, file='', dir='', line=0, column=0, flags=[], unsavedFiles.count=0, opt=off}
execute: Command{action=Command::Complete, file='/tmp/fail/main.cpp', dir='', line=13, column=3, flags=['-x', 'c++', '-working-directory', '/tmp/fail/', '-std=c++14', '-I/opt/Qt/5.7/gcc_64/include'], unsavedFiles.count=1, opt=off}
libclang: crash detected in code completion

I tried to reproduce the error with this command but clang success to get the right completion:

$ clang++ -I/opt/Qt/5.7/gcc_64/include -fPIC -x c++ -fsyntax-only -Xclang -code-completion-at=main.cpp:13:6 -std=c++14 main.cpp
COMPLETION: monChannel : [#QWebChannel#]monChannel

(note that if I don't use -fPIC, Qt give an preprocessor error, but still there is the completion written. Could it be the problem ? I also set the column at 6)

I tried to reproduce with irony-server:

$ irony-server complete main.cpp  13 3
-x c++ -working-directory /tmp/fail -std=c++14 -I/opt/Qt/5.7/gcc_64/include
execute: Command{action=Command::Complete, file='main.cpp', dir='', line=13, column=3, flags=['-x', 'c++', '-working-directory', '/tmp/fail', '-std=c++14', '-I/opt/Qt/5.7/gcc_64/include'], unsavedFiles.count=0, opt=off}
libclang: crash detected in code completion

;;EOT

I tried with 3 versions of libclang/llvm including one without assertion (#206) and 3 versions of Qt. It always crashes.

I didn't take a look at irony code but is there any way to get more informations about what is happening ?

Izzeri commented 7 years ago

I've been having this exact problem for a few days now, except it crashes when I type "std" (but only in certain files, it seems? At least it feels like it only happens in certain files, but I could be wrong). What happens is emacs freezes for a second or two when I type "std", and then Flycheck indicates that something is wrong (showing a ? for number of errors in the modeline). I'm using Spacemacs on OSX 10.11.6. I compiled the Irony server with the libclang included with Xcode, using headers that I found in some other issue thread about compiling the server on OSX. My .clang_complete looks like the following:

-I./../
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
-I/usr/local/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-I/usr/include
-I/Library/Developer/CommandLineTools/usr/include/c++/v1
-DUSE_INTERNAL

Irony server doesn't seem to be able to find the standard library without these includes (except the ./../, that's for a local library (also, just using ../ didn't seem to work, even though it works when compiling, hence ./../)). Here is an excerpt from a log file for when the server crashes:

execute: Command{action=Command::Parse, file='<working dir>/mod.cpp', dir='', line=0, column=0, flags=['-x', 'c++', '-working-directory', '<working dir>, '-std=c++11', '-I./../', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1', '-I/usr/local/include', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include', '-I/usr/include', '-I/Library/Developer/CommandLineTools/usr/include/c++/v1', '-DUSE_INTERNAL'], unsavedFiles.count=1, opt=off}
execute: Command{action=Command::Diagnostics, file='', dir='', line=0, column=0, flags=[], unsavedFiles.count=0, opt=off}
execute: Command{action=Command::Complete, file='<working dir>/mod.cpp', dir='', line=348, column=55, flags=['-x', 'c++', '-working-directory', '<working dir>', '-std=c++11', '-I./../', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1', '-I/usr/local/include', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include', '-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include', '-I/usr/include', '-I/Library/Developer/CommandLineTools/usr/include/c++/v1', '-DUSE_INTERNAL'], unsavedFiles.count=1, opt=off}
libclang: crash detected in code completion

I'm afraid I can't show the file and location where it crashes, for privacy reasons.

I was able to recreate this crash by running the server manually, and doing a parse, diagnostics, and then complete command in a certain file on a certain spot.

Please tell me if I can provide any additional information that might be of help!

Edit: Clarification: It doesn't only crash when I type "std", it crashes from a bunch of other stuff as well. Can't really find what those cases have in common.

sebastiencs commented 7 years ago

It's strange because it crashes 9 out of 10 cases (with irony-server command). I don't know why it doesn't crash sometimes.

Also I took a look at irony-server code: Without the call to clang_reparseTranslationUnit(), there is no more crash with libclang. But now the completion with company/checking with flycheck is too slow and make irony unusable.

sebastiencs commented 7 years ago

Commenting this line in TUManager.cpp fixes the crash:

parseTUOptions_ &= ~CXTranslationUnit_CacheCompletionResults;

Sarcasm commented 7 years ago

Sorry for the silence,

The issue does not seem trivial and I have limited time, I appreciate that you were able to nail down the issue to a piece of code.

A few questions:

What system/version do you use?
What is your version of irony-server + libclang? Output of ~/.emacs.d/bin/irony-server --version will do.
The comment above the line you commented explains the reason the line exists. Do you notice this kind of issues? I think the test case was to create 2 files, 1 header foo.hpp and 1 source foo.cpp. Declare a struct in the header. Complete the struct in the .cpp. Edit the header to add a new member. Retrigger completion in .cpp. The new member does not show up. Another difference with and without this flag is explained in the commit a1b045c7f5f0377748fe2deaa31b70cd3e13379d, does it still happen if the line is removed?

Sarcasm commented 7 years ago

Also, until I can reproduce the issue.

Can you try to reproduce the issue under valgrind using irony-server directly?

Izzeri commented 7 years ago

It's really weird. It feels like on some days, the server crashes with every other statement I write, and on other days it doesn't crash at all. I suspect it just depends on which files I'm currently working with on those days, but it's still a bit odd. I think I've only seen it crash when working in .cpp files. I was working exclusively in .h files on thursday and friday, and I don't remember it crashing at all. I can't seem to produce any crashes right now, don't know why.

My system is a MacBook Air, running OS X El Capitan 10.11.6. irony-server --version returns:

irony-server version 0.2.0
Apple LLVM version 7.3.0 (clang-703.0.31)

I don't currently have time tinkering with irony-server, so I can't try removing lines and recompiling right now.

Sarcasm commented 7 years ago

I tested removing the line @sebastiencs talked about:

parseTUOptions_ &= ~CXTranslationUnit_CacheCompletionResults;

I haven't seen any downside yet, I tried with a somewhat older version of libclang.

Would be nice to have a minimal example that we can reproduce, understand, give to libclang. Personally I haven't noticed the issue yet on my setup.

OS X Clang version are always a little bit hard to reason about for me. Looks like it matches 3.8.0, which is what I use.

Izzeri commented 7 years ago

Yeah, I'd prefer being able to use the vanilla LLVM clang, but it's cumbersome on a Mac. This is the best (only) guide I've found for mapping Apple LLVM versions to vanilla LLVM versions. It says my version is probably based on LLVM 3.8.0.

I'll have time to try removing that line and recompiling the server today. Will report back if I notice anything.

sebastiencs commented 7 years ago

I'm using Fedora 24 with Cinnamon as DE
I compiled irony-server from the master branch, same with libclang:

$ ~/.emacs.d/irony/bin/irony-server --version 
irony-server version 0.2.0
clang version 4.0.0 (http://llvm.org/git/clang.git 79d2d0e7ab930d2e2647df40e7b3db969f709a7e) (http://llvm.org/git/llvm.git 61926b476d4c7e097763c7807f2d7e23601dc790)

I also tried with the llvm releases tarball from http://llvm.org/releases/ (3.8.0 and 3.8.1)

Just try your test case, and the new member appears in the completion. The only problems I have is that the completion with template class doesn't work sometimes, or if I declare a variable as 'auto'
I run valgrind with irony-server (linked with libclang compiled with debug info). See the attached file, I removed the memory leaks. valgrind.txt

Sarcasm commented 7 years ago

Thanks for the feedback.

I do not have time to investigate more deeply but I committed the fix you proposed (https://github.com/Sarcasm/irony-mode/commit/4b63b809c9643b90d396cbcc1ed0a53659888f4d).

People will complain if there are downside I guess...

Izzeri commented 7 years ago

I'm still having this problem, though it's not as frequent. It seems like it mainly happens in files that make heavy use of macros to generate code.

Sarcasm / irony-mode

libclang crash #326