implement memory tracing for heap objects

[GoogleCodeExporter]

Our friends ask us this:
https://code.google.com/p/chromium/issues/detail?id=305234
===========
Many UaF bugs involving bindings and refcounted object are very difficult to 
debug. What usually happens is that something deref's a ref counted object too 
often, so the object dies while the bindings code still has a ref pointer to 
the object.

To help with debugging such issues, it would be nice to have all ref and deref 
stack traces (or at least the last N stack traces).
===========

I think we should not limit such capability to just ref/undef, 
instead we could implement __asan_trace_memory_access(void *addr)
that will store the last N accesses with their stack traces in the heap 
chunk's metadata. Then, when a bug is reported, we could print all of the
traces.

Original issue reported on code.google.com by konstant...@gmail.com on 15 Oct 2013 at 12:02

[GoogleCodeExporter]

Another use case I can think of: we can attach stack traces to some memory 
objects allocated by libc (which we can't unwind through). E.g. we may 
intercept getcwd() and attach the stack trace to the result of the actual 
getcwd() to obtain useful stack trace.

Original comment by vonosmas@gmail.com on 15 Oct 2013 at 3:01

[GoogleCodeExporter]

Carrying over from https://code.google.com/p/chromium/issues/detail?id=241892 
I'm speaking from experience of debugging the opposite problem, i.e. leaked 
references.

The way I usually approach this is by overriding ref()/deref() 
(AddRef()/Release()) methods of the class I'm interested in, making them print 
the stack trace and "this". Of course, this can sometimes produce a huge number 
of stacktraces, in which case Jochen's approach might work better.

On the other hand, stack traces don't tell you everything you need to know, and 
you might want to insert extra logging code. And when you do that, you might 
want to see the stack traces printed in the correct chronological sequence 
w.r.t. the other logging output (I don't have a strong example of this off the 
top of my head, though). The proposed approach doesn't allow that.

One other advantage of the proposed approach is that we wouldn't have to 
override ref()/deref() in subclasses anymore - we could just put the ASan hooks 
in base::RefCounted. I would expect this to have a serious performance impact, 
though, so we would have to keep this functionality disabled by default. If we 
could have it enabled always on bots, I can see it being useful for tracking 
down errors that we can't reproduce. Barring that, all this achieves is to save 
the small amount of work required to override the ref()/deref() methods.

In short, I think this has a limited use case, but we need to carefully weigh 
the potential benefits against the complexity increase.

Original comment by earth...@chromium.org on 13 Dec 2013 at 2:06

[GoogleCodeExporter]

#1 - That's a separate matter, and ASan already does that in some libc 
interceptors.

Original comment by earth...@chromium.org on 13 Dec 2013 at 2:07

[GoogleCodeExporter]

Yeah, I'd hope that with oilpan, those bugs will magically disappear from 
blink...

Original comment by jochen@chromium.org on 13 Dec 2013 at 2:08