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

[Sohail Somani (Fizz Buzz Inc.) via cfe-dev]

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.
Sohail

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