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

[Sean Silva via llvm-dev]

On Tue, Jul 12, 2016 at 12:48 AM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> Hi Sean,
>
> Sean Silva wrote:
> >
> > 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"
>
> I'm not sure about this -- is manipulating a pointer as an integer
> (without loading or storing through it) included in "access"?  IOW,
> will asan catch this bug at all:
>
> DenseMap M;
> M[BB] = 5;
> delete BB;
> BB = new BasicBlock()
> return M[BB];
>
> ?
>
> It seems to be fine with
>
> int main(int, char **) {
>      int *f = new int[5];
>      delete[]f;
>      return f == (int*) 100;
>
> }
>


Yeah, this is the reason that I qualified my ASan comment with "if we do
try to access through any of these dangling pointers".

-- Sean Silva


>
>
> > 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/20160712/44d3da65/attachment.html>