Error : Damage after normal block

Not having seen that specific message before, I can''t determine which program/library is generating that message. However, it sounds like you''re writing to memory you don''t own.

Quite often, debug versions of memory libraries will allocate, for example, 8+N bytes of memory when you ask for N. The eight extra bytes are split, four before your "normal block" of memory and four after.

The debug memory libraries will then write a particular pattern of data to that block. Later, when you deallocate that memory, they check those extra bytes to see if they are intact (ie, they still contain that particular pattern).

If they do, everything is fine. If the pattern has changed, the likely reason is that you are overwriting memory. Quite often, errors like this come from writing outside of an array by using an array index too large for that array.


---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

I''ve seen this error a few times, and every time I''ve seen it it was because one of the .dll''s I''m using wasn''t properly synched (older version and the API calls got slightly lost). Granted this is a project which creates an awful lot of .dll''s. If you aren''t making your own .dll''s you might have a corrupt one somewhere possibly. Try a full clean and rebuild first, though you probably already have.

Hi!
This problem happens if you:
-Allocate mem for an array
-Then acces elements of the array you have not allocated(for example: array=malloc(10); array[11]=x)
-And then free this array

P.s.:It happens only with the debug build not if you select to build a release build.And it happens at the free-call.

HTH, XBTC!

This is part of the MFC''s DEBUG_NEW mechanism. When you allocate a block of memory, it actually allocates three blocks:
1) A block of 4 bytes before your block of memory, which it fills with the repeating pattern 0xFD
2) Your actual block of memory, which it fills with 0xCD
3) A block of 4 bytes after your block of memory, which it also fills with the pattern 0xFD

The memory block is filled with 0xCD so you can be sure that you aren''t relying on the memory being initialized to 0x00.

When you delete this block of memory, MFC checks the blocks before and after to make sure they still equal 0xFD. The error message you''re seeing is reporting that the block after the memory allocation has been corrupted, i.e. it no longer equals 0xFD.

If possible, I would set a breakpoint where this memory is allocated, pull up the memory window to look at the contents following the block (the 4 bytes of 0xFD), and step through your program until you see it change. If your program is large, just step through the outermost loop until you see it change inside a function; then restart the program, step into that function, etc.

I''ve seen this happen the same way fel has: usually when it happens to me, it''s because I''ve updated some libraries but haven''t copied the .H files into my include folder, so it''s using the old interface with a new .LIB or .DLL and things just aren''t lining up in memory.

FYI, when you allocate stack variables in the debug build, it fills that space with the pattern 0xCC, for the same reason that heap memory is filled with 0xCD.

There, now you all know what the CC, CD, and FD''s are all about.

One thing I want to clarify that someone else said, even though you don''t get the error in a non-debug build, it doesn''t mean that there isn''t a problem. Memory that shouldn''t be modified is getting modified and this can result in very strange crashes.

(Assuming you are using VC)

One thing you can do is use _CrtCheckMemory to validate all allocated memory.

_ASSERTE( _CrtCheckMemory( ) );

Even though _CrtCheckMemory will not tell you where memory is getting trashed, it helps to narrow down the code causing the problem.

For example:

_ASSERTE( _CrtCheckMemory( ) );
InvokeBigMonsterRoutine ();
_ASSERTE( _CrtCheckMemory( ) );

Assuming that the first assert didn''t fire, and the second one did, you would know that somewhere in the InvokeXXX routine, memory is getting trashed. You could then start placing asserts in that routine to narrow down the lines even more.

Tim

Thanks guy''s... The suggestion seem pretty close to the mark. I''m using vectors with the subscript operator so it''s possible that I''m doing assignment''s somewhere thats out of bounds (I keep forgetting that it''s still possible to do that with STL.). I''ll replace all subscript assignments with .at()''s and see if that helps if not I''ll try that cool debugging trip...

TimSmith : I was kind of thinking that too, ie this is a warning for something quite bad. Generally in the past I''ve been careful about fence posting errors, but with STL managing memory on just about every container operation I was caught out by this.

I guess it''s good that STL doesn''t check for validity before assignment, it would really slow down large assignments...

Thanks all for the lesson on debug memory differences..

gimp