<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jul 12, 2016 at 12:48 AM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sean,<br>
<br>
Sean Silva wrote:<br>
 ><br>
 > ASan's reuses it less often, but keeps it poisoned so that dangling pointers get caught. This makes it less likely that<br>
 > re-use will cause invalid analysis results. BUT it makes it more likely that when we access a dangling pointer, it falls<br>
 > into a poisoned heap area. So the net result is that it catches dangling pointers better.<br>
 ><br>
 > Or to put it another way, the "heap slot reuse causes invalid analysis results" situation is actually a subset of "we<br>
 > access a dangling pointer"<br>
<br>
I'm not sure about this -- is manipulating a pointer as an integer<br>
(without loading or storing through it) included in "access"?</blockquote><div><br></div><div>No, sadly.</div><div><br></div><div>However, ASan provides tools that we could extend things like DenseMap with. For example, we could potentially have DenseMap check whether any pointer keys in the map are poisoned. We probably wouldn't want to *always* do this, but we could have a particular mode that controls this inside of DenseMap.</div><div><br></div><div>Then, when accessing the map (say, clearing, rebucketing, probing, with an explicit "check" or a randomized walk of the entire table) we could have it directly call __asan_address_is_poisoned or we could have it directly read (and discard) the first byte of underlying storage at that address. This is guaranteed to be safe and correct for valid pointers but will synthesize a nice error if a dangling pointer is left in the map.</div><div><br></div><div>We could probably handle most common idioms by allowing you to directly *remove* a dangling pointer, but crashing if we probe past one and periodically (on lookups only) check the entire map. I suspect we might even be able to make that the default for non-"void*" keys and change anyone using raw pointers that aren't to allocated objects to use "void*" as the key type.</div><div><br></div><div>-Chandler</div></div></div>