<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 11:04 PM, Dennis Luehring <span dir="ltr"><<a href="mailto:dl.soluz@gmx.net" target="_blank">dl.soluz@gmx.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Am <a href="tel:30.10.2013%2016" value="+73010201316" target="_blank">30.10.2013 16</a>:44, schrieb Kostya Serebryany:<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wed, Oct 30, 2013 at 1:49 AM, Dennis Luehring <<a href="mailto:dl.soluz@gmx.net" target="_blank">dl.soluz@gmx.net</a>> wrote:<br>
<br>
> it would be nice to have an clang feature to instrument cleanup freed<br>
> stack/heap space<br>
> with an defined bit pattern (0, 0xfff...,) - this way it would be easier<br>
> to find stack/heap missuse<br>
><br>
> before dtor end(exception chain) the object space will be nulled<br>
> before function/method/ctor end(exception chain) stack space will be nulled<br>
> before mallocs-free the allocated space is nulled (problematic when using<br>
> other librarys)<br>
><br>
> i little bit in the area of the addresssanitizer but should be faster, but<br>
> without the auto-detection of missuse<br>
><br>
> what do you think<br>
><br>
<br>
These are two different tasks: heap and stack.<br>
<br>
For heap, you need to change the malloc implementation, not clang/llvm.<br>
In fact, many malloc implementation do this already in debug mode.<br>
<br>
For stack, yes, you can to this.<br>
It will be rather expensive -- in some cases more expensive than what asan<br>
does (!!).<br>
Consider you have a function with a large stack frame, e.g. 8K, which is<br>
called very frequently.<br>
Your proposal means we need to memset 8K of stack on every call.<br>
While asan only memsets 1K of shadow on every call.<br>
</blockquote>
<br></div>
so it would be better to extend AddressSanitizer to detect such cases<br></blockquote><div><br></div><div>This sounds similar to <a href="https://code.google.com/p/address-sanitizer/issues/detail?id=73">https://code.google.com/p/address-sanitizer/issues/detail?id=73</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
#include <cstring><br>
<br>
class A<br>
{<br>
public:<br>
   A(int x):_x(x){}<br>
   int _x;<br>
};<br>
<br>
//#define CLEAR_FOR_CRASH<br>
<br>
class B<br>
{<br>
public:<br>
   B(const A& a):_a(a){}<br>
   ~B()<br>
   {<br>
#if defined(CLEAR_FOR_CRASH)<br>
     ::memset(this,0xff,sizeof(B)); // invalidates B<br>
#endif<br>
   }<br>
   const A& _a; // want a copy but forget to remove & on refactor<br>
};<br>
<br>
class C<br>
{<br>
public:<br>
   C(const B& b):_b(b){}<br>
   const B& _b;<br>
};<br>
<br>
int main()<br>
{<br>
  const A a(10);<br>
  const C c(a); // temporary B is created and destroyed<br>
  int x2 = c._b._a._x; // crashes on defined CLEAR_FOR_CRASH - else not<br>
<br>
  return 0;<br>
}<br>
<br>
<br>
</blockquote></div><br></div></div>