mfc >> Heap corruption in VC++ 6?

by Rusty » Tue, 02 Dec 2003 05:37:43 GMT

I'm using VC++6, with no third-party stuff.

My program compiles fine, runs well, and then when it closes I get a
"User breakpoint called" in some module, and in my trace window I get

HEAP[Nocrack.exe]: Heap block at 002F5ED0 modified at 002F5F08 past
requested size of 30
HEAP[Nocrack.exe]: Invalid Address specified to RtlValidateHeap(
2f0000, 2f5ed8 )
HEAP[Nocrack.exe]: Heap block at 002F5ED0 modified at 002F5F08 past
requested size of 30

I'm using the STL heavily, and it looks like it's in the STL
deallocation that this happens (but I'm not sure).

I looked into this a bit, and most folks figure it's because you're
using debug libs with a release DLL or something - but that's not the
case here. Just to be sure, I tried changing the build options to
Multihreaded DLL from Debug Multithreaded DLL (I had to ignore
MSVCRT.DLL) and got the same problem.

If I run (Ctrl+F5) instead of running debugged (F5), it works fine
(but I'd imagine that the error is still there and is simply not being
flagged).

Can anyone point me in the right direction? Thanks.

Russ


mfc >> Heap corruption in VC++ 6?

by Kim Youngjin » Tue, 02 Dec 2003 08:31:27 GMT


> If I run (Ctrl+F5) instead of running debugged (F5), it works fine

It does not work fine, just looks like working fine.

Such errors are occured when you access out of bounds memory.
For example you allocate 10 array and try to access 11th block.

I think this is the problem of memory management of windows.
It allows to access not a valid memory bounds.

Check and make sure that you use your memory correctly.
Memory boundary and not to try to access deallocated or already freed
memory.





mfc >> Heap corruption in VC++ 6?

by Scott McPhillips [MVP] » Tue, 02 Dec 2003 09:40:29 GMT





The error is not associated with deallocation. It's just that doing
deallocation gives the heap manager a chance to check everything, and
during deallocation it finds corruption that happened at some earlier
time. The corruption could be from anywhere in your code. What would
really help pin it down is figuring out what variable was at 002F5ED0.
The error indicates it is a 30 byte block but byte [56] was written!
Probably an indexing/pointer bug in your code.

--
Scott McPhillips [VC++ MVP]



Heap corruption in VC++ 6?

by Rusty » Tue, 02 Dec 2003 10:24:56 GMT

On Mon, 01 Dec 2003 20:40:29 -0500, "Scott McPhillips [MVP]"


I have clearly identified the problem:

I am an idiot.

Thanks for your help.





RE: Heap corruption in VC++ 6?

by eddoonline » Tue, 02 Dec 2003 13:07:59 GMT

Hi Rusty,

It looks like the debug memory manager is catching an overrun of a memory
block. When you invoke your application under the debugger, the memory
manager allocates some additional space just before and after the
allocation and initializes it to a specific value. The RtlValidateHeap call
detects that this buffer has been changed and throws the error you're
seeing.

Have you built debug symbols for your project? If so, what does the
callstack look like. I'm guessing that you are either deleting or
reallocating a memory block. It may take a bit of work but you may be able
to backtrack the allocation and figure out where the overrun is occuring.
Barring that though, you could use Pageheap functionality with the
GFLAGS.EXE utility to force the application to crash when the overwrite
occurs. The following link contains some details on how to do this.


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/
ddtools/gflags_00s3.asp

Sincerely,
Ed Dore [MSFT]

This post is "AS IS" with no warranties, and confers no rights.






Heap corruption in VC++ 6?

by Rusty » Wed, 03 Dec 2003 14:25:11 GMT

On Tue, 02 Dec 2003 05:07:59 GMT, XXXX@XXXXX.COM ("Ed


This GFLAGS is great - an excellent tool that I was totally unaware
of. I've never even heard of it before, but it's helping greatly.

Thank you!

Russ




Similar Threads

1. heap corruption

is this the correct pageheap enable?

gflags -p /enable prophecy city.exe /full

mk


2. OpenGL32.dll causes heap corruption under WinXP

3. Can't determine cause of heap corruption or orphaned lock using cdb

4. Heap corruption in derived class constructor

5. Throwing from DLL causes heap corruption

I have a DLL linked to my own app that works fine when throwing from DLL to 
application. But with a customer application I get a heap corruption 
exception when the thrown exception goes out of scope in the catch clause. 
I've copied the stack below. To the best of my knowledge, both app and DLL 
are linked against the VC6 multi-threaded debug DLL runtime. Any idea 
what's going wrong here?

_CrtIsValidHeapPointer(const void * 0x09b56480) line 1697
_free_dbg_lk(void * 0x09b56480, int -572662307) line 1044 + 9 bytes
_free_dbg(void * 0x09b56480, int -572662307) line 1001 + 13 bytes
operator delete(void * 0x09b56480) line 49 + 16 bytes
MSVCRTD! exception::~exception(void) + 45 bytes
AxisSafetyException::~AxisSafetyException() + 208 bytes
MSVCRTD! DestructExceptionObject(struct EHExceptionRecord *,unsigned char) 
+ 85 bytes
MSVCRTD! __FrameUnwindToState + 807 bytes
MSVCRTD! __FrameUnwindToState + 458 bytes
MSVCRTD! __InternalCxxFrameHandler + 800 bytes
MSVCRTD! __InternalCxxFrameHandler + 227 bytes
MSVCRTD! __CxxFrameHandler + 44 bytes
NTDLL! 7c9037bf()
NTDLL! 7c90378b()
NTDLL! 7c90eafa()
MSVCRTD! _CxxThrowException@8 + 57 bytes

6. heap corruption/full pageheap

7. Heap Corruption with static libraries

Hello.
I've encountered a problem that I cannot resolve. Here it is.
On one side, I got a static library, implementing function 
static_lib_func(char * buffer){
    for(i=0;i<20;++i)
        buffer[i] = T[i] ^ 0x01;
}
This static library is built using MT code generation.
On the other side, I got an application (also MT), using that function such 
like this :
 while (i<20){
     char * buf = new char[dynamic_length];
     static_lib_func(buf);
     delete[] buf;
 }

The problem is that randomly, a "corruption of the heap" exception message 
is raised during the loop execution. Sometimes after 2 loops, sometimes after 
10 loops, but the 20 loops cannot  finish executing. The execution stops in 
function:
//Assert the lock associated with the passed file handle
 int __cdecl __lock_fhandle (int fh) of file osfinfo.c
with the return value FALSE

Thank you very much for bringing any tiny clue !

Guillaume

8. calloc causing heap corruption