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

[Gábor Márton via cfe-dev]

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/20180624/c487bb3a/attachment.html>