[cfe-dev] Asserts in Clang crashes my Kdevelop

[Vladimir Voskresensky - Oracle]

On 01/28/15 02:46 PM, Lucas Tanure wrote:
> 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.
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
https://www.youtube.com/watch?v=uEtFOtkzMO4&index=9&list=PLKCk3OyNwIzuRh2YsM2MtFAwB_qEWC5Rn

>
> Thanks
>
>
>
> --
> Lucas Tanure
> +55 (19) 988176559
>
> On Wed, Jan 28, 2015 at 12:10 AM, Richard Smith <richard at metafoo.co.uk 
> <mailto:richard at metafoo.co.uk>> wrote:
>
>     On Mon, Jan 26, 2015 at 11:46 PM, Olivier J. G. <olivier.jg at gmail.com
>     <mailto:olivier.jg at gmail.com>> wrote:
>
>             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.
>
>
>     Nonetheless, if you can provide us with testcases for the crashes, we'd
>     appreciate them.
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150128/549c8439/attachment.html>