dbgheap.c assertion
Paul.B.Folbrecht@JCI.Com Monday, December 30, 1996 Environment: VC++ 4.1, Win95 & NT 4.0 I am getting an assertion on line 1029 of dbgheap.c: if (!CheckBytes(pbData(pHead) + pHead->nDataSize, _bNoMansLandFill, nNoMansLandSize)) _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at 0x%08X.\n", szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)], pHead->lRequest, (BYTE *) pbData(pHead)); This is the situation: I have a tabbed dialog (using a CTabCtrl) with several pages. Changing a field on one page causes child windows (which are actually modeless dialogs) on another page to be dynamically destroyed and possibly recreated. The assertion comes when the dialog is closed, from the destructor of one of the child dialogs on the page I mentioned. The call stack is as follows: _free_dbg_lk(int 4, void * 0x00d850a0) line 1033 + 63 bytes _free_dbg(int 4, void * 0x00d850a0) line 970 + 13 bytes CObject::operator delete(void * 0x00d850a0) line 44 + 12 bytes CAnalogBarDlg::`scalar deleting destructor'() + 39 bytes CAnalogBarDlg is ultimately derived from CDialog (with two other intermediate base classes in between), and each level defines a virtual destructor. I know this is not likely enough information to diagnose the problem, and the immediate suspicion has to be that there is memory being corrupted, but I'd like to try to get a general idea of the kind of errors that would cause this, if possible. What has me perplexed is that I am virtually certain there are no memory overwrites or other errors that could cause this, and indeed the program continues with no other errors, and has no problems in release mode either. heapchk() returns valid at all times. -Paul Folbrecht Compuware Corp.
Kenneth A. Argo -- argo@rias.COM Tuesday, December 31, 1996 The assertion is a result of deleting something which the checking code = feels is invalid. This is most commonly called by deleting something 2 = times. Be sure after you call delete on a variable you set its value to = NULL. Ken ---------- From: Paul.B.Folbrecht@JCI.Com[SMTP:Paul.B.Folbrecht@JCI.Com] Sent: Monday, December 30, 1996 5:30 PM To: mfc-l@netcom.com Subject: dbgheap.c assertion Environment: VC++ 4.1, Win95 & NT 4.0 =20 I am getting an assertion on line 1029 of dbgheap.c: =20 if (!CheckBytes(pbData(pHead) + pHead->nDataSize,=20 _bNoMansLandFill, nNoMansLandSize)) _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at=20 0x%08X.\n", szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)], pHead->lRequest, (BYTE *) pbData(pHead)); =20 This is the situation: I have a tabbed dialog (using a CTabCtrl) = with=20 several pages. Changing a field on one page causes child windows=20 (which are actually modeless dialogs) on another page to be=20 dynamically destroyed and possibly recreated. The assertion comes=20 when the dialog is closed, from the destructor of one of the child=20 dialogs on the page I mentioned. The call stack is as follows: =20 _free_dbg_lk(int 4, void * 0x00d850a0) line 1033 + 63 bytes=20 _free_dbg(int 4, void * 0x00d850a0) line 970 + 13 bytes=20 CObject::operator delete(void * 0x00d850a0) line 44 + 12 bytes=20 CAnalogBarDlg::`scalar deleting destructor'() + 39 bytes =20 CAnalogBarDlg is ultimately derived from CDialog (with two other=20 intermediate base classes in between), and each level defines a=20 virtual destructor.=20 =20 I know this is not likely enough information to diagnose the = problem,=20 and the immediate suspicion has to be that there is memory being=20 corrupted, but I'd like to try to get a general idea of the kind of = errors that would cause this, if possible. What has me perplexed = is=20 that I am virtually certain there are no memory overwrites or other = errors that could cause this, and indeed the program continues with = no=20 other errors, and has no problems in release mode either. = heapchk()=20 returns valid at all times. =20 -Paul Folbrecht Compuware Corp.
Blane Nelson -- blanen@coresoft.com Tuesday, December 31, 1996 Paul, I've seen something like this before. Some objects on a dialog are what = MFC calls temp objects. MFC will pass you a pointer to the object (or = in some strange cases you created the object) but you are not allowed to = delete/release the object. MFC keeps a pointer to these temp objects = and when the dialog is destroyed it destroys all of the temp objects. = It sounds like you deleted one of these temp objects that MFC still has = a pointer to. Make sure that you did not delete/release the = CAnalogBarDlg object in your code. -Blane Nelson -Coresoft Technologies ---------- From: Paul.B.Folbrecht@JCI.Com[SMTP:Paul.B.Folbrecht@JCI.Com] Sent: Monday, December 30, 1996 9:30 AM To: mfc-l@netcom.com Subject: dbgheap.c assertion Environment: VC++ 4.1, Win95 & NT 4.0 =20 I am getting an assertion on line 1029 of dbgheap.c: =20 if (!CheckBytes(pbData(pHead) + pHead->nDataSize,=20 _bNoMansLandFill, nNoMansLandSize)) _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at=20 0x%08X.\n", szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)], pHead->lRequest, (BYTE *) pbData(pHead)); =20 This is the situation: I have a tabbed dialog (using a CTabCtrl) = with=20 several pages. Changing a field on one page causes child windows=20 (which are actually modeless dialogs) on another page to be=20 dynamically destroyed and possibly recreated. The assertion comes=20 when the dialog is closed, from the destructor of one of the child=20 dialogs on the page I mentioned. The call stack is as follows: =20 _free_dbg_lk(int 4, void * 0x00d850a0) line 1033 + 63 bytes=20 _free_dbg(int 4, void * 0x00d850a0) line 970 + 13 bytes=20 CObject::operator delete(void * 0x00d850a0) line 44 + 12 bytes=20 CAnalogBarDlg::`scalar deleting destructor'() + 39 bytes =20 CAnalogBarDlg is ultimately derived from CDialog (with two other=20 intermediate base classes in between), and each level defines a=20 virtual destructor.=20 =20 I know this is not likely enough information to diagnose the = problem,=20 and the immediate suspicion has to be that there is memory being=20 corrupted, but I'd like to try to get a general idea of the kind of = errors that would cause this, if possible. What has me perplexed = is=20 that I am virtually certain there are no memory overwrites or other = errors that could cause this, and indeed the program continues with = no=20 other errors, and has no problems in release mode either. = heapchk()=20 returns valid at all times. =20 -Paul Folbrecht Compuware Corp.
| Вернуться в корень Архива |