Asserts in Clang crashes my Kdevelop

Hi,

Newbie here.
I’m trying to understand a few issues in kdevelop clang plugin, and for that I would like to use clang in debug mode.
But when I compile 3.5.1 for Debug, asserts come too, and this give a crash in kdevelop:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd73ea700 (LWP 7083)]
0x00007fffef77ba97 in raise () from /usr/lib/libc.so.6
#0 0x00007fffef77ba97 in raise () from /usr/lib/libc.so.6
#1 0x00007fffef77ce6a in abort () from /usr/lib/libc.so.6
#2 0x00007fffef7748bd in __assert_fail_base () from /usr/lib/libc.so.6
#3 0x00007fffef774972 in __assert_fail () from /usr/lib/libc.so.6
#4 0x00007fffaab15bd7 in clang::comments::Lexer::lexVerbatimBlockFirstLine (this=0x7fffd73e85f0, T=…) at /home/tanure/workspace/llvm/tools/clang/lib/AST/CommentLexer.cpp:468
#5 0x00007fffaab15e56 in clang::comments::Lexer::lexVerbatimBlockBody (this=0x7fffd73e85f0, T=…) at /home/tanure/workspace/llvm/tools/clang/lib/AST/CommentLexer.cpp:517
#6 0x00007fffaab1521c in clang::comments::Lexer::lexCommentText (this=0x7fffd73e85f0, T=…) at /home/tanure/workspace/llvm/tools/clang/lib/AST/CommentLexer.cpp:295
#7 0x00007fffaab16cc8 in clang::comments::Lexer::lex (this=0x7fffd73e85f0, T=…) at /home/tanure/workspace/llvm/tools/clang/lib/AST/CommentLexer.cpp:802

I just want to compile clang in debug mode without asserts.

How I compile:

svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_351/Final/ llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_351/final/ clang
cd llvm/tools/clang/tools
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/tags/RELEASE_351/final/ extra
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/tags/RELEASE_351/final/ compiler-rt

and in other folder , like clang_build
cd clang_build
cmake -DCMAKE_INSTALL_PREFIX=/opt/llvm -DCMAKE_BUILD_TYPE=Debug -DPYTHON_EXECUTABLE=/usr/bin/python2.7 llvm (path to llvm)

make
make install

So, there is any way to compile in debug without asserts ?

Thanks

Lucas Tanure <tanure@linux.com> writes:

I'm trying to understand a few issues in kdevelop clang plugin, and for that I
would like to use clang in debug mode.
But when I compile 3.5.1 for Debug, asserts come too, and this give a crash in
kdevelop

This is probably pretty serious. Asserts that fire in clang or llvm
generally indicate a serious problem, and the behaviour without asserts
is pretty suspect in these cases.

You really should look into why you're hitting these asserts in the
first place, rather than disabling them, as it's pretty likely that some
of your problems are related.

So, there is any way to compile in debug without asserts ?

If you really do need this, you could try passing
-DLLVM_ENABLE_ASSERTIONS=OFF to cmake.

This is just asking to crash later with sigsegv. =/ That particular
assertion is:

void Lexer::lexVerbatimBlockFirstLine(Token &T) {
again:
  assert(BufferPtr < CommentEnd);

So, failing that assertion is equivalent to memory OOB access.

Barring an enormous push to stabilize Clang and make it less crashy, you
have two options:
1. Try to recover from assertion failures and segfaults with
CrashRecoveryContext
2. Rig up a separate process to run clang in from kdevelop

A separate process will be more stable but far more effort.

You'd think compilers wouldn't crash very often, but take a look at the
list of crashers found by AFL:
http://llvm.org/bugs/buglist.cgi?quicksearch=fuzz&list_id=66187
While these are all bugs we'd like fixed, it's not clear how soon that will
happen. Until then, KDevelop and IDEs in general will need to cope with
compiler crashes somehow.

void Lexer::lexVerbatimBlockFirstLine(Token &T) {
again:
  assert(BufferPtr < CommentEnd);

So, failing that assertion is equivalent to memory OOB access.

Barring an enormous push to stabilize Clang and make it less crashy, you
have two options:
1. Try to recover from assertion failures and segfaults with
CrashRecoveryContext
2. Rig up a separate process to run clang in from kdevelop

A separate process will be more stable but far more effort.

You'd think compilers wouldn't crash very often, but take a look at the
list of crashers found by AFL:
http://llvm.org/bugs/buglist.cgi?quicksearch=fuzz&list_id=66187
While these are all bugs we'd like fixed, it's not clear how soon that
will happen. Until then, KDevelop and IDEs in general will need to cope
with compiler crashes somehow.

While it seems like this assertion failure would lead to a crash, I should
note that I haven't run into any crashes during AST traversal when clang is
in release mode. OTOH, clang compiled in debug mode will fairly regularly
come up with assertions during AST traversal.

For the initial parsing we see plenty of crashes and asserts in both debug
and release, but libclang already runs those in a CrashRecoveryContext, so
it's not usually an issue (unless you're trying to run KDevelop in gdb...).

In short, KDevelop/kdev-clang runs smoothly with release-build clang and is
not really usable when clang is built w/ assertions.

-Olivier JG

Nonetheless, if you can provide us with testcases for the crashes, we'd
appreciate them.

Hi,

Well, I just jumped in kdevelop, just because I need a good editor to develop linux kernel. I don’t understand the code of kdevelop and clang.
My “test case” is import the top makefile from linux tree and wait to clang to parse. Just that. It crashes a few minutes latter in a thread from clang parser.

I know that this asserts are important, but I get this tip to disable asserts from kdevelop community. I think that would take a few days for me to understand what’s happening.
I really would like to understand and fix this issue. If someone is willing to help me and mentor would be great.

I compiled all llvm, clang, kdevelop and kdev-clang plugin in my Arch Linux Desktop. My goal is to have a good editor for linux kernel, with the same features that I had with vim+cscope.

Thanks

I’m using NetBeans for that. Last time I checked It handled Linux kernel pretty well. I use “Project from existing sources” and build it once from the IDE to allow it auto detect compiler options like in [1]. It works reasonably fast if you give it enough memory (i.e. whole LLVM+CLang+Extra source tree is parsed within 1 min on my linux laptop when I start "netbeans -J-Xmx2G --cachedir /ram/mounted/dir "). Hope it helps, Vladimir. [1] Studio is based on top of NetBeans

Hi,

I got the offender:
./util/duchainify/duchainify -V -d ~/workspace/src/linux/drivers/scsi/ipr.c

There is any way for me to help to fix that ? Or clang is so difficult to understand, that is better to let clang guys to solve it ?
Should I fill a new bug ? Or there is already a bug for linux source parsing ?

Thanks

Please file a bug report with preprocessed file attached. If you have debug version of clang handy you can run it with clang -cc1 -fsyntax-only ipr.c and see where/why it asserts and try to fix it (if you’re not afraid of C++ like some kernel devs are :P).

https://bugs.kde.org/show_bug.cgi?id=343950