[llvm-dev] Adding asan poison to Recycler and ArrayRecycler

[Nicolai Hähnle via llvm-dev]

On 07.10.2016 00:31, Mehdi Amini wrote:
>> On Oct 6, 2016, at 4:54 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> I intend to add address sanitizer (un)poison calls to Recycler and ArrayRecycler
>
> That’s a great thing to do! Looking forward for it.
>
>> since I spent a few hours tracking down a bug in the AMDGPU backend that turned out to be a use-after-free that would have been detected by asan if it weren't for the Recycler. See https://reviews.llvm.org/D25313.
>>
>> Naturally, such a change exposes a bunch of bugs or things that are dodgy and happen not to be problematic today, but might easily break in the future, across all backends. I have prepared patches to fix all the issues in the CodeGen/AMDGPU lit tests; all the non-AMDGPU fixes are rolled into the patch above (although it probably makes sense to commit them first as a separate change before switching asan on). But it's clearly not my job to fix the inevitable build bot regressions in other backends.
>
> Unfortunately, that does not sound as clear to me as it sounds to you apparently.
>
> If you want to change the Recycler/ArrayRecycler in a way that it is exposing bugs with ASAN in other places in LLVM, you’ll have first to fix these bugs.

The point is that the bugs are already there, it's just that nobody 
notices them. I'm totally behind a rule that says not to introduce any 
regressions, but what I'm proposing doesn't do that.

What I'm proposing is basically equivalent to introducing a buildbot 
with a previously untested configuration. Actually, that makes me think 
that there should be an XFAIL-based approach to this.

Anyway, I'm going to go with Justin's (1) + (2) bug-filing suggestion 
first, and see how quick people are at fixing the issues.

Cheers,
Nicolai