If you ever get this VS.NET error in C, read on for a fix:

Debug Error! DAMAGE: after Normal block (#97) at 0×00350040.

This was caused by an infite mutual recursion between a rehash() function and the linear probing hash() function, all because I check null but didn’t calloc() the rehashed elements. There are times when malloc() just won’t do. You have to make sure that you initialize elements to NULL before checking against NULL–otherwise they’ll contain garbage.

Another source of this error is a buffer overflow. Imagine if you call

mem = malloc(number_elements)

for an int* array rather than

mem = malloc(number_elements * sizeof(int))

That will be “fine” until you call free(mem): the runtime will tell you that you’ve just damaged your heap.

5 Responses to “DAMAGE: after Normal block”

1. ratte says:

   6/8/2005 at 11:20 am

   same error with the following reason:
   added a pointer variable to a base class of my plugins and forgotten to rebuild them. the error arised after deleting a plugin instance, but only when I accessed the member, even if I only set it to 0 in the constructor.

   Reply
2. Janie says:

   9/25/2005 at 11:59 pm

   Hey.
   Thanks for the help.

   It’s obvious programmin error, i know…
   But sometimes you just need to be pulled back to the ground.

   - Janie

   Reply
3. Witton Bell says:

   3/6/2006 at 8:10 pm

   I have a same problem in VC++ 6.0.there are some code as follows:
   struct T
   {
   int * pt;
   …
   };

   struct M
   {
   vector m_vctT;
   …
   };

   map m_mapM;

   M * pM = new M;
   m_mapM.insert(make_pair(1,pM);

   T * pt = new T;
   pt = …
   pM->m_vctT.push_back(pt);

   so,I write some code for free memory in a destructor function,as follows:
   for(map::iterator iter = m_mapM.begin; iter != m_mapM_end();iter++)
   {
   if((*iter->second) != NULL)
   {
   delete (*iter->second);
   }
   }

   but run at delete (*iter->second) with debug mode,it report DAMAGE: after Normal block (#XX) at 0×XXXXXXX

   who can tell me how to fix this problem? Please mail to me : witton@163.com. Thanks very much!

   Reply
4. Dimas Ricchi says:

   7/10/2007 at 4:16 pm

   alloc more any bytes is a bug of the compiler

   Reply
5. G-Man says:

   12/4/2008 at 10:10 pm

   Thank you so much for explaining this! I knew most of what you said already and yet something about it made it click what my error was. I thought I was already doing as you suggested, but I actually was off by one byte (don't ask).

   Reply