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

[Ella Oikawa via cfe-dev]

Hi George,

As you mentioned above, assertions are good for developers. But for users,
they are annoyed, especially when the scan process is nearly finished. My
team is developing the tool, but the users are from other teams, so the
"production" version for these teams should be "stable" enough, even though
all the mistakes are hidden.
The errors vary from project to project, and only a few open source
projects in our benchmark will trigger the assertions in clang, so they are
hard to model. And my team has very few developers, we do not have enough
time to model these errors, neither the user team (they even do not want to
provide their code to us).
My team is using the old version (3.3) of the llvm/clang project (the
oldest code may be written originally by Zhongxing Xu, the writer of the
paper which the clang static analyzer is based on, even older than the
clang static analyzer itself), I am not sure these "bugs" in clang and llvm
still exists in the latest versions. And the count of developers limits us
from updating the clang/llvm version, as we have so many features to
develop and have limited time to do so.

Regards,
Ella

George Karpenkov <ekarpenkov at apple.com> 于2018年6月26日周二 上午2:38写道：

> Hi Ella,
>
> On Jun 24, 2018, at 1:23 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**.
>
>
> Each assertion failure is a bug you can report at bugs.llvm.org. Do you
> really get that many?
> We at Apple regularly run the clang static analyzer on huge chunks of the
> internal codebase, and in my understanding Google does the same,
> so I am quite surprised this is a problem for you.
>
>
> 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)
>
>
> I would really like to challenge your assumption here that assertions are
> unacceptable.
>
> A clean crash with an understandable stack trace means that the problem
> can be fixed.
> Adding layers of indirection which hide those failures means that the bug
> gets unnoticed,
> and the analyzer probably ends up doing something wrong.
>
> Could you clarify what is the common error mode for you?
>
> Regards,
> George
>
>
> 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/20180628/7166dd8a/attachment.html>