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

[David Blaikie via cfe-dev]

On Mon, Jun 25, 2018 at 12:59 PM Sohail Somani (Fizz Buzz Inc.) <
sohail at fizzbuzzinc.com> wrote:

>
>
>
> On Mon, Jun 25, 2018, at 3:22 PM, David Blaikie via cfe-dev wrote:
>
>
>
> On Mon, Jun 25, 2018 at 12:16 PM George Karpenkov <ekarpenkov at apple.com>
> wrote:
>
>
> On Jun 25, 2018, at 12:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Jun 25, 2018 at 11:51 AM George Karpenkov <ekarpenkov at apple.com>
> wrote:
>
>
> On Jun 25, 2018, at 9:38 AM, David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> So, yes, the reading of the Clang AST is a bit of a special case & hasn't
> met this interpretation of "do not crash on arbitrary inputs" - but the
> intent is that it does not crash on ASTs produced by the same version of
> Clang (if you model the "system" as the totality of a single clang writing
> something to disk then reading it back again - that is not expected to
> crash). So any assertions that are firing in that situation should be, I
> believe, considered to be programmer errors.
>
> Are you going outside that scope - and dealing with 'untrusted' ASTs
> potentially generated from other versions of Clang? Coming from unknown
> sources, etc?
>
>
> Generating AST by hand, or taking them from elsewhere is known to be very
> fragile, and we don’t really have a check for it.
> In that case assertions are a *good* thing, as at least they say that
> something went wrong as opposed to e.g. silently ignoring the AST.
>
>
> Depends what the source is/what they're doing - might be a "best effort"
> sort of thing. "Hey, I have some AST lying around - analyze whatever parts
> of it you can".
>
> If so, then, yeah - forking is probably the only good bet, I would imagine.
>
>
> A proper fix here would be to e.g. have an ASTVerifier which could take an
> AST DAG and then return whether it’s valid or not.
>
>
> Yep, that'd be the ideal - though that's a lot of work (the set of
> invariants is large/not well known - basically all we have is "ASTs are
> correct by construction in Clang" as the definition of invariants) & I
> could imagine that these folks aren't in a position to do all that work -
> so "try to load it and bail out on assertions/crashes" might be the best
> tradeoff for them.
>
>
> One alternative is to have a special build where you redefine asserts to
> throw exceptions. Accomplishes similar goals without crashing the process
> or requiring forking. I've found (not with Clang) that customers are happy
> when they can copy-and-paste the contents of a dialog which says "BUG!" as
> opposed to a full on crash, especially if you can guarantee that the state
> of the application is safe (as it should be, if that particular set of
> assertions fires.)
>
> When the exception is thrown, you could silently log the relevant
> information and ask the user to submit as a bug over email.
>

Throwing exceptions through code not designed for exceptions is rather
fraught with peril... - good chance of at the very least memory leaks, or
some other leaks of state (at least in LLVM/Clang that should only leak as
far as LLVMContext and ASTContext sort of stuff... but that's the goal not
always the reality) that could corrupt further work, etc.


> Sohail
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180625/3d3ea72e/attachment.html>