[llvm-dev] Should analyses be able to hold AssertingVH to IR? (related to PR28400)

[Sean Silva via llvm-dev]

On Mon, Jul 11, 2016 at 11:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> Hi Sean,
>
> Sean Silva wrote:
> >
> >     But asan won't catch problems (insofar I understand how it works) if
> >     the free'ed BasicBlock is used as a key in a DenseMap or something --
> >     if another BasicBlock gets allocated to the same location we'll end
> up
> >     returning bad cached results.
> >
> >
> > ASan's allocator is specifically hardened against reusing memory, which
> > mitigates this, but I'm not sure by how much (but I think by a
> > significant amount).
>
> Do you mean it will re-use memory less often?  Won't that just hide
> the bug above?  If anything, I don't want ASan to "mitigate" bugs, I
> want it to make the bug trigger more often. :)
>

ASan's reuses it less often, but keeps it poisoned so that dangling
pointers get caught. This makes it less likely that re-use will cause
invalid analysis results. BUT it makes it more likely that when we access a
dangling pointer, it falls into a poisoned heap area. So the net result is
that it catches dangling pointers better.

Or to put it another way, the "heap slot reuse causes invalid analysis
results" situation is actually a subset of "we access a dangling pointer"
which is what we really want to catch (I mean "dangling" in a sense that a
pointer stays "dangling" even if its heap slot is reused). By avoiding
reuse of heap slots, the dangling pointer is more likely to be in a heap
slot that ASan is keeping poisoned and not reusing (hence it can detect the
error).

-- Sean Silva


>
> (Or did I just re-state what you were saying?)
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160711/f89e07d8/attachment.html>