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.

adnanhad commented: hi +0

Recommended Answers

All 5 Replies

after exiting from main, the following actions are performed:
a. call destructors of objects with static storage
b. call atexit functions
c. deinit the C runtime library
during this, it was detected that some dynamically allocated memory block is invalid. this can occur due to a variety of reasons; but the fragment pHead->nBlockUse usually indicates that you are trying to free memory that has already benn freed. (it is also possible that a block header was corrupted by writing beyond the bounds of allocated memory in an adjecent block). if there is no instance of any such error in your own code, it would have been caused by something incorrect in a library that you are using.

Look at the call stack and see which d'tor (destructor) is being called, that should tell you where the problem is..

I'm guessing you trashed the heap somewhere in your program, and it's only when the program exits that you actually find out about it.

http://msdn2.microsoft.com/en-us/library/5at7yxcs(VS.80).aspx
"Heap-Check Frequency Macros"
You can request that the heap be checked on a more frequent basis, which may help you to figure out where it is going wrong.

> pUserData
You could also put this into the "examine memory" window to see if you recognise the data which has trashed the heap.
One particular kind of overrun would be a string. In this case, you might recognise the text which has overwritten memory, and from that deduce the point in the code where it came from.

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.

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.

I had the same error, I was writting outside the memory allocation and when freeing the assertion was failing.

ror 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.

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.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.