Programming Forums - _CrtIsValidHeapPointer( pUserData )

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C++ (http://www.programmingforums.org/forum15.html)

- - _CrtIsValidHeapPointer( pUserData ) (http://www.programmingforums.org/showthread.php?t=13391)

_CrtIsValidHeapPointer( pUserData )

Hi,

I have a Win32 Console Application which is throwing the Debug Assertion Failed! .. _CrtIsValidHeapPointer( pUserData ) and followed by a Debug Assertion Failed! .. _BLOCK_TYPE_IS_VALID(pHead->nBlockUse).

After I did a Step by Step Debug strangely what I saw was it is throwing error once it is exittin the main function.

Unlike any character pointers and deletion of heap without its references as of when generally this error occurs I have no such instances.

please could you suggest a probable solution to this. please help.:(

The most common cause of such things after main (eg a heap pointer being detected as invalid, a system reset [under MS-DOS], a general protection fault [under windows], a core dump or bus error [under unix variants]) is pointer molestation in your code.

In short, somewhere in your application, you are doing an invalid operation on a pointer. Examples include falling off the end of an array (eg accessing element 8 in an array of length 6), dereferencing a NULL pointer or an uninitialised pointer, using a pointer that has previously been free()'d, using a pointer that has previously been deleted, etc etc.

The problem is that the crash is not occurring where the error actually is. The only thing that can be said for certain is that program crashes occur at or after execution of the code that is the culprit. Unfortunately, this is quite common.

The variations are endless. The way to track things down is also variable. A simple way is to comment out parts of your source code to narrow down what the offending part is.

according to the following call stack

NTDLL! 7c901230() 

NTDLL! 7c96cd80() 

NTDLL! 7c960af8() 

KERNEL32! 7c85e9cf() 

_CrtIsValidHeapPointer(const void * 0x00032b78) line 1697

_free_dbg_lk(void * 0x00032b78, int 1) line 1044 + 9 bytes 

_free_dbg(void * 0x00032b78, int 1) line 1001 + 13 bytes operator 

delete(void * 0x00032b78) line 351 + 12 bytes 

CString::FreeData() line 146 + 15 bytes 

CString::~CString() line 213 $E155() + 34 bytes 

doexit(int 0, int 0, int 0) line 353 

exit(int 0) line 279 + 13 bytes 

mainCRTStartup() line 345 

KERNEL32! 7c816fd7()

It is clear the error was occuring tryin to free the CString objects which incidentally I had made global due to the requirements. Hence I refactored my application and passed them as reference.:banana:

What I inferred from the situation is that while tryin to free up the Cstring memory it encountered that the heap had already been unintiallized. however it is still unclear to me how was the heap cleared before even C Runtime tried to unregister it. I never explicitly have defined any destructors.

Your inference is incorrect. You've eliminated a symptom, but not removed the cause.

If destruction of a global/static object causes an error then the cause is most likely a previous pointer molestation. As discussed in my previous post.

By moving the objects and passing them by reference (which I assume means you declared them as locals within main() or some other function, and pass them as arguments) all you have achieved is a change of the layout of data and other memory used by your program. That, in turn, simply changes what memory is corrupted when your code does pointer molestation. In this case, it happens to mean that the memory being corrupted is no longer related to the heap. But some memory, somewhere, is being corrupted -- and you have a bug which is likely to emerge, eventually.

Yeah u are correct!! that's y trying to analyze memory leaks using tools like Dev Partner.

For the time being I needed to roll out the Project Prototype for testing

Haha, I love the term 'pointer molestation'. :)

Anyways, what you could try, if tracing through the code in a debugger is getting you nowhere, is to apply a couple safeguards. First, with any of your pointer math, employ bounds checking to ensure the resultant pointer is used only if it is within the bounds of the array or allocated block. Second, ensure all your pointers are NULL when they are not valid (ie, before initialization and after free() or delete). Trying to use such a pointer is much easier to track than using a pointer that's pointing to limbo, as access through a NULL pointer will typically raise an exception right away, while other pointer misuse may cause corruption of your program's memory space, leading to other, hard to discover bugs (which often obfuscate a much more fundamental problem).