[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 4:31 PM, David Blaikie wrote:
> 
> 
> 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.
Ah yes, it only works if everything is RAII'ed to the hilt. Good call.


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