Programming Forums > Application Development > C++

shouvik · Jun 20th, 2007, 12:57 AM

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.

grumpy · Jun 20th, 2007, 8:03 AM

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.

shouvik · Jun 21st, 2007, 2:33 AM

according to the following call stack

(Toggle Plain Text)

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.

grumpy · Jun 21st, 2007, 5:32 AM

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.

shouvik · Jun 21st, 2007, 8:29 AM

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

lectricpharaoh · Jun 21st, 2007, 7:36 PM

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

Jun 20th, 2007, 12:57 AM	#1
shouvik Newbie Join Date: Jan 2007 Posts: 16 Rep Power: 0	_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. __________________ Thanks and Regards Shouvik

Jun 21st, 2007, 2:33 AM	#3
shouvik Newbie Join Date: Jan 2007 Posts: 16 Rep Power: 0	Global to Local according to the following call stack (Toggle Plain Text) 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() 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. __________________ Thanks and Regards Shouvik

Jun 21st, 2007, 8:29 AM	#5
shouvik Newbie Join Date: Jan 2007 Posts: 16 Rep Power: 0	Correct 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 __________________ Thanks and Regards Shouvik

Jun 21st, 2007, 7:36 PM	#6
lectricpharaoh Caffeinated Neural Net Join Date: Jun 2005 Location: Dry west coast of Canada Posts: 1,033 Rep Power: 5	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). __________________ And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot. - Vaarsuvius, Order of the Stick

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Jun 20th, 2007, 8:03 AM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,223 Rep Power: 5	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.

Jun 21st, 2007, 5:32 AM	#4
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,223 Rep Power: 5	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.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)