[cfe-dev] clang 3.2 libclang: crash detected during reparsing

Argyrios Kyrtzidis akyrtzi at gmail.com
Tue Apr 9 12:54:08 PDT 2013

On Apr 5, 2013, at 4:34 AM, Erik Verbruggen <erik.verbruggen at me.com> wrote:

> On 5 apr. 2013, at 00:45, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
>> On Apr 4, 2013, at 12:14 AM, Oliver Giles <ogtifs at gmail.com> wrote:
>>> I just tried this again with the latest clang from svn. The original snippet works but the next lines in my original code are:
>>> CXCursor cursor = clang_getTranslationUnitCursor(tu);
>>> CXSourceRange sr = clang_getCursorExtent(cursor);
>>> CXToken* tokens;
>>> unsigned numtokens;
>>> clang_tokenize(tu, sr, &tokens, &numtokens);
>>> CXCursor* cursors = new CXCursor[numtokens];
>>> clang_annotateTokens(tu, tokens, numtokens, cursors);
>>> Appending even the first line of this (clang_getTranslationUnitCursor) to the example I gave earlier causes a segfault in the clang 3.3 library.
>> Fixed in r178800. FYI, it looks like the CXTranslationUnit object that you get is null, so there was a problem during parsing.
> I've also noticed this behaviour, where a null-TU gets returned when parsing failed. It's usually unrecoverable for clang, and the only way to debug it is to turn on the option to write messages to stdout/stderr. I never got around to ask it, but is there a way to get these error messages even when the TU is null? I mean, the only way for e.g. an IDE to handle  this is to silently ignore it, and that's not very helpful...

How about introducing a new CXTranslationUnit_ flag to pass to clang_parseTranslationUnit, which will cause that function to still return a CXTranslationUnit object on failure (maybe marked as erroneous or something) which the client will only use to get any stored diagnostic.
I think we also need some changes in ASTUnit because I believe that if clang::createInvocationFromCommandLine fails we don't keep the diagnostic.

> -- Erik. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130409/12274e57/attachment.html>

More information about the cfe-dev mailing list