Created attachment 111651 [details] console output on the crash. I have an annoying Crash on C++ project. I have Kdevelop 5.2.1 running on my Fedora machine from the repos and also in a VM as AppImage on Ubuntu 16.04 and both crash when indexing/parsing the source. The project is https://github.com/riebl/vanetza on commit c33b7f6c9d5bed49a5dfbb948963a9895a144129. As soon as I add the project to a kdevelop session its being indexed and at some point inevitably crashes before finishing the parsing. First I get the output from a libclang crash and the I get either "double free or corruption (!prev)" or "corrupted double linked list". I have the full commandline output of the first one appended. libclang: crash detected during parsing: { 'source_filename' : '<arbitrary path>/vanetza/vanetza/geonet/data_request.cpp' 'command_line_args' : ['clang', '-ferror-limit=100', '-fspell-checking', '', '-Wunused-parameter', '-Wunreachable-code', '-Wall', '-std=c++11', '-nostdinc', '-nostdinc++', '-xc++', '-isystem/usr/include/c++/7', '-isystem/usr/include/c++/7/x86_64-redhat-linux', '-isystem/usr/include/c++/7/backward', '-isystem/usr/local/include', '-isystem/usr/lib64/clang/4.0.1/include', '-isystem/usr/include', '-imacros', '/tmp/kdevelop.rA5119'], 'unsaved_files' : [], 'options' : 781, } I really like KDevelop and use it for all my cmake related proejcts and most other in regard to C/C++.
I know this doesn't help you, but it probably makes more sense to report this to libclang, since the bug is there ...
Hello Sven, I'll do that. But still KDevelop should not crash if possible. It seems to me that libclang does itself some magic when it crahes so it can generate this fancy output. Between not having the full power of syntax highlighting and the IDE crashing everytime I prefer not having the IDE crash and maybe some error notification. Nonetheless: can you give me some pointer on how to call the parsing myself? Can I just run the command_line args as a bash command? Is that sufficient?
The problem really is that the built-in crash "recovery" in llvm/clang is not bullet-proof. While it catches the crash signal to output this message, the data afterwards can be corrupt and crash outside of the "guarded"/"recoverable" parse thread. At that point, we just crash completely. To fix this, we'll have to patch llvm/clang. What version of that are you using? If this crash is easily reproducible with your project, that can help in finding a patch to fix it. To workaround this in KDevelop, we'll have to pull of a huge refactoring to only access libclang from an external helper process. This is not easy to do at all, and would require quite some work. Still, since we are all affected by this just like you, I actually wonder if we can pull it off... Eventually :) And to answer your question, in theory you could just run the command_line_args (join the array, remove the single quotes). But if it's not crashing then (which I guess won't happen), then it's probably due to how we use libclang vs. how clang itself works. I.e. we concurrently access the Index in libclang, which should be OK from an API pov. But clang itself is not multithreaded. Similarly, we run parse jobs on multiple TUs, whereas clang runs it only on one TU at a time.
Hi Millian, thank you for the clarification. If KDevelops stack / memory is corrupted there's nothing to be done. I understand. I ran the commands on another system with clang 3.8 and there it did not crash. Though this does not say anything. But with your guess that it behaves differently when called from kdevelop, I would like to try creating a minimal example for the clang people which does not involve kdevelop if possible. Can you point me to the source where the parsing is triggered? The system I tested it on and could produce the crash logs runs a 4.0 clang. I'll test it there too.
the code is in kdevelop/plugins/clang, but it's going to be interesting to figure out what we are actually all calling here, and in what threads. if you want to track this down, it would be cool if you could write a script based on ltrace that finds all libclang API calls to automatically build a reproducer :)
Hi, small update: it does not crash any more. I tried with KDevelop 5.2.3 on Fedora and 5.3.0/1 AppImage on Ubuntu Xenial. Sadly I did not manage to trace this problem to the clang calls - this would have been a cool experience. Best Regards, Christian
Thanks for the feedback, will close this for now.