idea: feature to force cleanup of freed stack/heap - useful enough?

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

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.

--kcc

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;
}

> 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

This sounds similar to
https://code.google.com/p/address-sanitizer/issues/detail?id=73

sounds also similar

https://code.google.com/p/address-sanitizer/issues/detail?id=83

doesn't your talk(new feature of ASan) on 2013 LLVM Developers' Meeting address my case?

  * Stack-use-after-scope detector finds uses of stack-allocated objects
    outside of the scope where they are defined.

http://llvm.org/devmtg/2013-11/#talk6

+samsonov