Show stacks for unpoison & poison

[GoogleCodeExporter]

For normal malloc/free memory, a use-after-free results in the stack for the 
allocation, the deallocation, and the final use.

For arena memory, a use-after-poison would ideally have the stack for the most 
recent unpoison, the poison, and the final use.  In addition to the allocation 
for the arena itself, I guess.

Original issue reported on code.google.com by jruder...@gmail.com on 4 Jun 2013 at 7:55

[GoogleCodeExporter]

This is doable, but would slow down (un)poisoning and make it more complex: 
even if we're going to save a stack trace for each memory region poisoning, 
we'll have to store it somewhere (there is no metadata or redzones for 
arbitrary user-provided memory).

Original comment by samso...@google.com on 5 Jun 2013 at 8:59

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think it would at least be very helpful to have an option (default off) to 
enable this. We use poisoning/unpoisoning heavily at Mozilla to mark 
freed/allocated memory in our own allocators.

Original comment by decoder...@googlemail.com on 5 Jun 2013 at 10:14

[GoogleCodeExporter]

This actually *is* a bit tricky to implement.
In regular malloc-ed memory we have the redzone which we use to store all the 
metadata.
For the pool-alloced memory we don't have a redzone, so we will need to store 
that
data somewhere else. A lock-free resizable hash-table? 

Original comment by konstant...@gmail.com on 5 Jun 2013 at 10:19

[GoogleCodeExporter]

Maybe we can implement (resizable, but with limited capacity) hash_table 
last_poisoning_stack[(addr, size)].

That is, if we call __asan_poison_memory_region(addr, size) for the same (addr, 
size) twice, the second call stack will overwrite the first one. Then, when 
we're trying to report poisoning stack on failure, we scan the whole table and 
find the latest poisoning touching the given address.

Original comment by samso...@google.com on 5 Jun 2013 at 10:28