[cfe-dev] idea: feature to force cleanup of freed stack/heap - useful enough?

Dennis Luehring dl.soluz at gmx.net
Wed Oct 30 23:04:51 PDT 2013


Am 30.10.2013 16:44, schrieb Kostya Serebryany:
> On Wed, Oct 30, 2013 at 1:49 AM, Dennis Luehring <dl.soluz at gmx.net> wrote:
>
> > it would be nice to have an clang feature to instrument cleanup freed
> > stack/heap space
> > with an defined bit pattern (0, 0xfff...,) - this way it would be easier
> > to find stack/heap missuse
> >
> > before dtor end(exception chain) the object space will be nulled
> > before function/method/ctor end(exception chain) stack space will be nulled
> > before mallocs-free the allocated space is nulled (problematic when using
> > other librarys)
> >
> > i little bit in the area of the addresssanitizer but should be faster, but
> > without the auto-detection of missuse
> >
> > what do you think
> >
>
> These are two different tasks: heap and stack.
>
> For heap, you need to change the malloc implementation, not clang/llvm.
> In fact, many malloc implementation do this already in debug mode.
>
> For stack, yes, you can to this.
> It will be rather expensive -- in some cases more expensive than what asan
> does (!!).
> Consider you have a function with a large stack frame, e.g. 8K, which is
> called very frequently.
> Your proposal means we need to memset 8K of stack on every call.
> While asan only memsets 1K of shadow on every call.

so it would be better to extend AddressSanitizer to detect such cases

#include <cstring>

class A
{
public:
    A(int x):_x(x){}
    int _x;
};

//#define CLEAR_FOR_CRASH

class B
{
public:
    B(const A& a):_a(a){}
    ~B()
    {
#if defined(CLEAR_FOR_CRASH)
      ::memset(this,0xff,sizeof(B)); // invalidates B
#endif
    }
    const A& _a; // want a copy but forget to remove & on refactor
};

class C
{
public:
    C(const B& b):_b(b){}
    const B& _b;
};

int main()
{
   const A a(10);
   const C c(a); // temporary B is created and destroyed
   int x2 = c._b._a._x; // crashes on defined CLEAR_FOR_CRASH - else not

   return 0;
}





More information about the cfe-dev mailing list