[llvm-commits] [PATCH] Keep going after errors in AddressSanitzer

[Reid Watson]

Alex,
You're quite right -- I developed this for projects which are clean
under standard ASan, but full of initialization issues.  It would make
sense to fix up the serious issues that this would introduce in other
use cases.  Thanks for pointing this out, and thanks for the link.

Kostya,
This was a quick hack to speed up the process of finding all
initialization order issues and blacklisting them.

The problem was:
* We have a large codebase, which is clean under ASan, but has a
surprising number of initialization order issues
* Blacklisting takes one compile/run cycle for each global to be found
and added to the blacklist
* The compile command changes after each iteration, so we end up
rebuilding the entire world each time we add a global to the
blacklist.
* The proper way to fix these globals relies on changes which will
take significant time to get approved due to using new language
features.

This patch worked great for this task, and saved me a lot of time
waiting for compiles to finish.  However, it seems that even with a
fair bit of touching up, it would still be slow, possibly flaky, and
in general against the spirit of ASan.  If it doesn't land upstream, I
think I'm fine with that, as this was an extremely unusual use case.

Thanks for reviewing,
Reid


On Thu, Sep 6, 2012 at 1:36 AM, Kostya Serebryany <kcc at google.com> wrote:
> Also, could you give us your rationale for this?
>
> Several people asked this feature because their code is too buggy and they
> want to see all bugs before fixing any.
> So far I have resisted...
>
> --kcc
>
>
> On Thu, Sep 6, 2012 at 12:31 PM, Alexander Potapenko <glider at google.com>
> wrote:
>>
>> Reid,
>>
>> Have you tested this patch on a real-world code?
>> I think recovering from errors might be trickier than you suppose it to
>> be.
>> Some types of bugs, e.g. wild stores, may introduce more bugs if they
>> corrupt the heap or the internal tool state.
>> The simplest way to treat such errors will require to drop a store if
>> it's accessing unaddressable memory.
>> Another approach is to write the stored value somewhere else in order
>> to allow further loads to see it.
>>
>> I suggest you to take a look at Martin Rinard's "Failure-Oblivious
>> Computing and Boundless Memory Blocks"
>> (http://people.csail.mit.edu/rinard/paper/sma05oblivious.pdf)
>>
>> HTH,
>> Alex
>>
>> On Thu, Sep 6, 2012 at 6:51 AM, Reid Watson <reidw at google.com> wrote:
>> > Hi all,
>> >
>> > I've attached a couple of patches which add support for ASan to continue
>> > when an error is encountered.  In order to not wreck performance, the
>> > decision to enable this must be made at compile time with -mllvm
>> > -asan-keep-going.  If the option is off (by default) then the
>> > instrumented
>> > code will be 100% identical, with no performance change.
>> >
>> > Code Review:
>> > LLVM: https://codereview.appspot.com/6492085/
>> > compiler-rt: https://codereview.appspot.com/6493086/
>> >
>> > Thanks,
>> > Reid
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>>
>>
>>
>> --
>> Alexander Potapenko
>> Software Engineer
>> Google Moscow
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>