Free Heap block modified after it was freed

Dear All,

I have the following problem:

Environment:
Visual Studio 6.0, Service Pack 6, C++, Windows XP
Software is using “Microsoft.Jet.OLEDB.4.0”
Software is having about 30 threads

After a view hours of operation in debugger, the software stops with the message box “User defined breakpoint”.

Message in output window is:
HEAP[App.exe]: HEAP: Free Heap block 5cbf760 modified at 5cd2f4c after it was freed

Output in callstack window:

NTDLL! 7c911230()
NTDLL! 7c959b79()
NTDLL! 7c9369a9()
NTDLL! 7c97e062()
NTDLL! 7c95a5d0()
NTDLL! 7c9368ad()
MSJET40! 1b005262()
MSJET40! 1b04af35()
MSJET40! 1b01a6f2()
05356890()

Memory and 5cbf760:

05CBF760 14 2D 15 24 AC 14 18 01 78 01 34 05 48 AE C9 05 EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE and so on …

Memory at 5cd2f4c:
05CD2F4C EE FC EE FE EE FE EE FE EE FE EE FE EE

Here is this FC. This is causing the problem.
I have no idea, how this FC was written to this address. But before allocating memory the debugger checks the memory for the sequence of FE EE. FC is not expected and so the debugger stops the software.
Has anybody an explanation what FC in terms of memory means?
I also can not explain the callstack. This thread is not the main thread and no thread I did start (they all have names). The software is doing inter process communication to a service by COM. Maybe it is a callback from this service?

Thanks for some good advice.

Dirk.

The way memory works in debug is that the debug version of MFC allocs all block a bit bigger than they need to be, it then puts some magical bytes 0x0BADFOOD into the bytes that are just ahead of and just behind the memory you actually get. So allocating just enough memory tostore "Hello world!" (simplistically speaking of course) becomes something like 0x0BADFOODHello World!0x0BADFOOD. When it comes time to free up the memory, MFC is not worried about the "Hello World!", but tests that the "guard-bytes" are still equal to 0x0BADFOOD, if not you get a exception. Primarily this tells you that someone wrote off-of the end of your memory-block by mistake.

so...I am going to take a stab here, if you look at your process, there is more than one thread? If you are 100% sure there are not any extra threads from elsewhere, disregard this response. Otherwise re-scan the FAQ sticky at the top of this forum.

OK, IMHO it looks like the crash is on a thread spawned someplace else, as the call-stack seems to be in NTDLL, not in your process EPSILON.EXE main thread.

You are going to want to look carefully at what you did just before the crash (I assume program is closing normally here). It may be that you passed a block of data to an API/interface and it was smaller than expected, or that you passed a duff pointer to an API or other library/control. To find your baby, backup the project, and comment out most of your code, and see if it runs (some features will be missing of course). Keep adding code back in untill you get close.

Alternately post more detail on the bug, and more people will try help you.

PS: It also happens (nasty) that if you use MFC extension dlls together, and end up passing memory from a release-compilled dll into a debug-compilled dll which then ends up freeing it, that the debug dll will throw() because it will look for the "guard-bytes" which are not actually there. So don't mix dlls if you can help it.

Thanks for your reply. My application has running around 30 threads and is quit big. For this it is hard to comment parts, but I will try by configuration to deactivate some parts. Any comment to the value 'FC'? Is it any special?
What information would be also helpful to solve my problem?

The FC is a pretty common junk byte. The 0x0BADFOOD is a kind of HEX for "Bad Food" :-) , it is also easy to spot in a dump, so if you ever see bad-food in your actual data, you know your data got a bit FAT on bad-food.

OK, enough mirth.
I imagine it's a huge database application and the threads all service remote users? I am not a OLEDB fundii, so I do not know a lot about the library and interface methods where you do actually pass data, I assume your com IDL interface classes are good, and there are no interface-version issues? The COM interface should actually sort out threading issues in your code, and make sure data passed is good too. So if bashing the interface yields no results after a short time, start looking elsewhere. I once wasted ages trying to blame an API when it was my own code at fault.

I call this part being a duck, a good duck will just nod and agree as you walk me through the code. Give it a try, grab your dog, and force it to look over your shoulder as you browse through all (I mean all) ofyour code, make small-talk all the time; the dog will "quack" when you get near to the bug.

OK, a duck is actually another developer who does not know your code, we call them a duck, because all they do is listen as you talk your way through the code, in the end you actually find the bug yourself, but the "duck" person is there jsut to force you to go through all of the code from start to finnish without skipping any parts, getting sidetracked, distracted.