<br><br><div class="gmail_quote">On Thu, Dec 15, 2011 at 10:40 AM, Alexander Potapenko <span dir="ltr"><<a href="mailto:glider@google.com">glider@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Uh-oh, then that's really a coincidence. Sorry for the false alarm.<br>
Then we really need to poison all the internal structures to see<br>
what's going on there.<br></blockquote><div>Done in r146531.</div><div>And I found the bug (with printf's help): <a href="http://code.google.com/p/address-sanitizer/issues/detail?id=19">http://code.google.com/p/address-sanitizer/issues/detail?id=19</a></div>
<div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
On Thu, Dec 15, 2011 at 9:31 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
> Could you please describe what the bug is?<br>
><br>
> I see that we have a use-after-return in __asan_register_global(uintptr_t<br>
> addr, size_t size, const char *name)<br>
> but this function is only used by the gcc variant which I did not touch for<br>
> ages. (Still, OMG)<br>
><br>
> In void __asan_register_globals(__asan_global *globals, size_t n),<br>
> which is used by the LLVM variant, I don't see a use-after-return.<br>
><br>
> (I like the idea to poison the memory allocated by LowLevelAllocator, I'll<br>
> land a patch shortly).<br>
><br>
> --kcc<br>
><br>
><br>
> On Thu, Dec 15, 2011 at 7:32 AM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>><br>
> wrote:<br>
>><br>
>> The attached patch fixes a use-after-return in ASan runtime.<br>
>> Previously stack-local objects representing global variables were<br>
>> passed to RegisterGlobal and put into the globals list that was<br>
>> scanned later, when those objects had been overwritten.<br>
>><br>
>> Related changes: s/Print/Report in RegisterGlobal (we may need the<br>
>> PIDs when analyzing the logs), poison the memory returned by the<br>
>> LowLevelAllocator to prevent possible corruptions.<br>
>><br>
>><br>
>> Alexander Potapenko<br>
>> Software Engineer<br>
>> Google Moscow<br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div class="HOEnZb"><div class="h5">Alexander Potapenko<br>
Software Engineer<br>
Google Moscow<br>
</div></div></blockquote></div><br>