2

I'm looking for a memory debug strategy in C++. I have written an application using QT. I'm using Windows 7. The used compiler is MinGW. In debug mode, I sometimes got the following debug message: HEAP CORRUPTION DETECTED: after Normal Block (#...) at 0x...

I guess, the following happens: The memory block is freed using delete. After that, the memory is used.

Most of the time, this will work without any problem. But sometimes, this leads to an application crash. My question is, how to debug this error? I'm thinking about replacing the operator new/delete.

Consider the following new/delete operator:

struct MemHandle
{
  void* ptr;
  size_t size;
}

void * operator new(std::size_t n) throw(std::bad_alloc)
{
  MemHandle Mem;
  void* p = malloc(n);
  Mem.ptr = p;
  Mem.size = n;
  //TODO: Store Mem
}
void operator delete(void * p) throw()
{
  MemHandle Mem = GetMemHandle(p);
  memset(p, 0, Mem.size);
  free(p);
}

In this case, when the memory is reused after delete, the program will immediately crash. Is this a good strategy, or do you have a better option?

MvHorssen
  • 111
  • 2
  • 12
  • Possible duplicate of [How to debug heap corruption errors?](http://stackoverflow.com/questions/1010106/how-to-debug-heap-corruption-errors) –  Jan 30 '16 at 20:04

2 Answers2

2

What you are trying to achieve is book-keeping for every memory allocation. There are memory profiling tools available (both commercial and open source), which do the same thing.
Valgrind is a great one but it is not available on Windows.
Purify is a commercial tool which works on windows, and if you are looking for an open source one than there is Dr Memory
You can explore some more tools here

Amitoj
  • 108
  • 3
0

My experience says that most wonderful tool for memory problems debugging is memory sanitizers(both GCC and LLVM supports them, -fsanitize-memory). It is pretty fast, easy to use and I have been in situations when valgrind sees nothing, but sanitizers do. Memory sanitizer will SIGABORT on detection of memory problem, so stack trace will be at your eyes immediately. Some of the disadvantages of sanizers are increased heap usage and slightly complicated build process but usually it is not a problem.

  • Since GCC supports it, it should be also available in MinGW, isn't it? – MvHorssen Jan 30 '16 at 19:42
  • Well, should be. But quick searching shows that at least at mid of 2015 MinGW didn't supported it. But you can try to use clang. –  Jan 30 '16 at 19:54
  • Either way, if your application is portable, or you can port suspected piece of code to Linux - you can use GCC or Clang with address sanitizer from there. –  Jan 30 '16 at 19:58
  • That's not an option, the application is too large to be easy portable to Linux. I have overloaded the new/delete operator with succes. – MvHorssen Jan 30 '16 at 21:00
  • Program may not crash in special case. Consider that your application reads previously freed memory and 0 values has a meaning for it(e.g. integer value). If user space memory allocator didn't returned allocated page, which contains freed chunk of memory, back to the OS - then you will not get a generic protection fault of page protection mechanism and you application will continue to work as nothing criminal happened. –  Jan 30 '16 at 21:36