How to debug heap corruption errors

Question

I am debugging a  native  multi-threaded C   application under Visual nbsp Studio nbsp 2008  On seemingly random occasions  I get a  Windows has triggered a break point     error with a note that this might be due to a corruption in the heap  These errors won t always crash the application right away  although it is likely to crash short after   The big problem with these errors is that they pop up only after the corruption has actually taken place  which makes them very hard to track and debug  especially on a multi-threaded application    What sort of things can cause these errors  How do I debug them    Tips  tools  methods  enlightments    are welcome

User · Answer

I had a similar problem - and it popped up quite randomly. Perhaps something was corrupt in the build files, but I ended up fixing it by cleaning the project first then rebuilding.

So in addition to the other responses given:

What sort of things can cause these errors? Something corrupt in the build file.

How do I debug them? Cleaning the project and rebuilding. If it's fixed, this was likely the problem.

User · Answer

I d like to add my experience  In the last few days  I solved an instance of this error in my application  In my particular case  the errors in the code were    Removing elements from an STL collection while iterating over it  I believe there are debug flags in Visual Studio to catch these things  I caught it during code review  This one is more complex  I ll divide it in steps   From a native C   thread  call back into managed code In managed land  call Control Invoke and dispose a managed object which wraps the native object to which the callback belongs  Since the object is still alive inside the native thread  it will remain blocked in the callback call until Control Invoke ends   I should clarify that I use boost  thread  so I use a member function as the thread function  Solution  Use Control BeginInvoke  my GUI is made with Winforms  instead so that the native thread can end before the object is destroyed  the callback s purpose is precisely notifying that the thread ended and the object can be destroyed

User · Answer

If these errors occur randomly  there is high probability that you encountered data-races  Please  check  do you modify shared memory pointers from different threads  Intel Thread Checker may help to detect such issues in multithreaded program

User · Answer

I have also faced this issue  In my case  I allocated for x size memory and appended the data for x n size  So  when freeing it shown heap overflow  Just make sure your allocated memory sufficient and check for how many bytes added in the memory

User · Answer

What sort of things can cause these errors    Doing naughty things with memory  e g  writing after the end of a buffer  or writing to a buffer after it s been freed back to the heap      How do I debug them    Use an instrument which adds automated bounds-checking to your executable  i e  valgrind on Unix  or a tool like BoundsChecker  Wikipedia suggests also Purify and Insure    on Windows   Beware that these will slow your application  so they may be unusable if yours is a soft-real-time application   Another possible debugging aid tool might be MicroQuill s HeapAgent

User · Answer

One quick tip  that I got from Detecting access to freed memory is this      If you want to locate the error   quickly  without checking every   statement that accesses the memory   block  you can set the memory pointer   to an invalid value after freeing the   block    ifdef  DEBUG    detect the access to freed memory  undef free  define free p   free dbg p   NORMAL BLOCK     int   amp p   0x666   endif

User · Answer

The best tool I found useful and worked every time is code review  with good code reviewers    Other than code review  I d first try Page Heap  Page Heap takes a few seconds to set up and with luck it might pinpoint your problem   If no luck with Page Heap  download Debugging Tools for Windows from Microsoft and learn to use the WinDbg  Sorry couldn t give you more specific help  but debuging multi-threaded heap corruption is more an art than science  Google for  WinDbg heap corruption  and you should find many articles on the subject

User · Answer

What type of allocation functions are you using   I recently hit a similar error using the Heap  style allocation functions     It turned out that I was mistakenly creating the heap with the HEAP NO SERIALIZE option   This essentially makes the Heap functions run without thread safety   It s a performance improvement if used properly but shouldn t ever be used if you are using HeapAlloc in a multi-threaded program  1    I only mention this because your post mentions you have a multi-threaded app   If you are using HEAP NO SERIALIZE anywhere  delete that and it will likely fix your problem      1  There are certain situations where this is legal  but it requires you to serialize calls to Heap  and is typically not the case for multi-threaded programs

User · Answer

You can detect a lot of heap corruption problems by enabling Page Heap for your application   To do this you need to use gflags exe that comes as a part of Debugging Tools For Windows  Run Gflags exe and in the Image file options for your executable  check  Enable Page Heap  option   Now restart your exe and attach to a debugger  With Page Heap enabled  the application will break into debugger whenever any heap corruption occurs

User · Answer

In addition to looking for tools  consider looking for a likely culprit  Is there any component you re using  perhaps not written by you  which may not have been designed and tested to run in a multithreaded environment  Or simply one which you do not know has run in such an environment   The last time it happened to me  it was a native package which had been successfully used from batch jobs for years  But it was the first time at this company that it had been used from a  NET web service  which is multithreaded   That was it - they had lied about the code being thread safe

User · Answer

You may also want to check to see whether you re linking against the dynamic or static C runtime library  If your DLL files are linking against the static C runtime library  then the DLL files have separate heaps   Hence  if you were to create an object in one DLL and try to free it in another DLL  you would get the same message you re seeing above  This problem is referenced in another Stack nbsp Overflow question  Freeing memory allocated in a different DLL

User · Answer

Application Verifier combined with Debugging Tools for Windows is an amazing setup   You can get both as a part of the Windows Driver Kit or the lighter Windows SDK    Found out about Application Verifier when researching an earlier question about a heap corruption issue    I ve used BoundsChecker and Insure    mentioned in other answers  in the past too  although I was surprised how much functionality was in Application Verifier   Electric Fence  aka  efence    dmalloc  valgrind  and so forth are all worth mentioning  but most of these are much easier to get running under  nix than Windows   Valgrind is ridiculously flexible  I ve debugged large server software with many heap issues using it   When all else fails  you can provide your own global operator new delete and malloc calloc realloc overloads -- how to do so will vary a bit depending on compiler and platform -- and this will be a bit of an investment -- but it may pay off over the long run   The desirable feature list should look familiar from dmalloc and electricfence  and the surprisingly excellent book Writing Solid Code    sentry values  allow a little more space before and after each alloc  respecting maximum alignment requirement  fill with magic numbers  helps catch buffer overflows and underflows  and the occasional  wild  pointer  alloc fill  fill new allocations with a magic non-0 value -- Visual C   will already do this for you in Debug builds  helps catch use of uninitialized vars  free fill  fill in freed memory with a magic non-0 value  designed to trigger a segfault if it s dereferenced in most cases  helps catch dangling pointers  delayed free  don t return freed memory to the heap for a while  keep it free filled but not available  helps catch more dangling pointers  catches proximate double-frees  tracking  being able to record where an allocation was made can sometimes be useful   Note that in our local homebrew system  for an embedded target  we keep the tracking separate from most of the other stuff  because the run-time overhead is much higher     If you re interested in more reasons to overload these allocation functions operators  take a look at my answer to  Any reason to overload global operator new and delete    shameless self-promotion aside  it lists other techniques that are helpful in tracking heap corruption errors  as well as other applicable tools     Because I keep finding my own answer here when searching for alloc free fence values MS uses  here s another answer that covers Microsoft dbgheap fill values

User · Answer

To really slow things down and perform a lot of runtime checking  try adding the following at the top of your main   or equivalent in Microsoft Visual Studio C     CrtSetDbgFlag  CRTDBG ALLOC MEM DF    CRTDBG LEAK CHECK DF    CRTDBG CHECK ALWAYS DF

User · Answer

You can use VC CRT Heap-Check macros for  CrtSetDbgFlag   CRTDBG CHECK ALWAYS DF or  CRTDBG CHECK EVERY 16 DF   CRTDBG CHECK EVERY 1024 DF

User · Answer

A very relevant article is Debugging Heap corruption with Application Verifier and Debugdiag

[c++] How to debug heap corruption errors?

Examples related to c++

Examples related to windows

Examples related to debugging

Examples related to heap