[cfe-dev] how to tolerate the assertion failures in llvm and clang

[Ella Oikawa via cfe-dev]

Thank you for your reply.
A member in my team also suggests so, I think I can have a try on the
forking solution. At least, it will make the program "works well" in the
production version on the server. If any other related problems occur, I
will reply here and hope to discuss about these if you want.
Thanks again.

Ella

Gábor Márton <martongabesz at gmail.com> 于2018年6月24日周日 下午5:25写道：

> Hi,
>
> We are struggling with the same problem with my team. We work on cross
> translation unit (CTU) static analysis. Sometimes the AST node of a
> function imported by the ASTImporter is not complete or wrong which causes
> assertion failures in the analysis engine or in the checkers. However if we
> had known that the function could not be imported then we wouldn't have
> started to import that, this way preventing the assert to fire and the
> crash of the process. Note, when the assertions are disabled, usually a
> segmentation fault happens.
>
> The original intention of the assertions in the LLVM infrastructure is to
> signal programming errors. They are really useful to catch errors - made by
> the LLVM/Clang programmer - as early as possible.
> See https://llvm.org/docs/CodingStandards.html#assert-liberally .
> Generally, we say that we should distinguish between programming errors
> and errors in the input. Programming errors should be handled with asserts,
> errors in the input should be handled with other means (some projects use
> exceptions).
> However, in our special case of the CTU, the AST is an input. Which can be
> wrongly assembled by the ASTImporter. Unfortunately the checkers cannot
> distinguish whether the error is because of a programming error in the
> checker itself or whether the AST as an input is wrong.
>
> Here is what we thought so far: Do a fork before the actual import and if
> the child died then don't start the import at all. This seems quite
> complicated and performance issues may arise. Also this may just hide some
> real errors, so we did not start to implement it. Rather we have the
> strategy now to gradually fix all the assertions. Sooner or later the
> ASTImporter will provide a complete and correct AST and the checkers are
> also changed to be able to handle a crippled AST. Until then we have
> crashes but every week we have fewer. And very importantly, we plan to hide
> the crash report from our users since it is useful only to the developers.
>
> Hope this helps,
> Gabor
>
>
>
> On Sun, Jun 24, 2018 at 10:24 AM alan snape via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> My team is developing a static analysis tool based on clang and llvm, but
>> the assertion failures in the source code of llvm and clang will always
>> crash the program execution, which is not acceptable in a **stable
>> product**. The tool analyzes the functions one by one in the Call Graph SCC
>> order, so is there any way to tolerate the assertion failures and continue
>> the analysis on the next function when assertion failures occur on calling
>> some APIs of clang and llvm? (crashes only the analysis of the function (the
>> analysis methods of the FunctionDecl) being analyzed, not the entire
>> program)
>>
>> Thanks,
>> Ella
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180625/4a89d53a/attachment.html>