<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">Ah, my bad, I missed '&' in main. <div>There are quite a few similar cases when asan will miss a bug in fully optimized code, while </div>
<div>it will not miss it at lower opt levels. </div><div><br></div><div>--kcc <br><div><br><div class="gmail_quote">On Sat, Nov 3, 2012 at 5:22 PM, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu" target="_blank">criswell@illinois.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<div>On 11/3/12 4:06 AM, Kostya Serebryany
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt">Also note that this is not the kind of bug for which asan
is good.
<div>If we are dereferencing an uninitialized pointer, there is
a high chance that the program will SEGV w/o any tool.</div>
<div>If we are unlucky and the garbage is accidentally equal to
some valid address, asan will not catch it either. </div>
<div>Valgrind (and work-in-progress MemorySanitizer) will catch
this. <br>
</div>
</div>
</blockquote>
<br></div>
Kostya, I think you're misreading the test case. He's storing a
64-bit value into a 32-bit pointer on a 32-bit platform. The
pointer value in f() is initialized (at least in the case where the
compiler's not optimizing away things due to undefined behavior).
The problem is that a 64-bit store doesn't fit into a 32-bit
pointer.<br>
<br>
ASan is catching that when the load isn't optimized away, and I've
verified that mainline SAFECode does as well. It also appears that
SAFECode finds the error when the noinline attribute is removed, but
I think that's a bug in how we integrated SAFECode into Clang (the
store should be optimized away by the LLVM optimizations, but it
isn't).<br>
<br>
Rafael, for now, if you want to get more pedantic behavior out of
ASan and SAFECode, you might want to try reducing the optimization
level. However, your test case brings up a good point: should there
be an option to clang that makes tools like ASan and SAFECode more
or less pedantic (either by reducing optimization or making checks
more picky)? It might make a good question at our BoF session next
week. :)<br>
<br>
-- John T.<div><div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt">
<div><br>
</div>
<div>--kcc <br>
<br>
<div class="gmail_quote">On Sat, Nov 3, 2012 at 5:38 AM, Eli
Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, Nov 2, 2012 at 6:27 PM, Rafael
Espíndola<br>
<<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>>
wrote:<br>
> I just tried asan on an optimized 32 bit build of<br>
> -------------------------------------<br>
> #include <stdint.h><br>
> __attribute__((noinline))<br>
> void f(uint64_t *p) {<br>
> *p = 42;<br>
> }<br>
> int main() {<br>
> void *p;<br>
> f((uint64_t*)&p);<br>
> }<br>
> ------------------------------------<br>
><br>
> and it correctly catches the invalid access. If I
comment the<br>
> attribute, the optimizers find and exploit the
undefined behavior and<br>
> asan fails to report it. Is this the expected
behavior? Is this<br>
> something that needs -fcatch-undefined-behavior
instead?<br>
<br>
</div>
For performance reasons, asan runs at the end of the
optimization<br>
pipeline, so it doesn't check loads which get removed by
the IR<br>
optimizers.<br>
<span><font color="#888888"><br>
-Eli<br>
</font></span>
<div>
<div><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div></div>