Results 1 to 8 of 8
-
September 29th, 2004, 10:34 AM#1
 Member
- Join Date
- Feb 2004
- Location
- Seattle, USA
- Posts
- 137
 What causes "Invalid Address specified to RtlValidateHeap"?
I'm working on a fixing up an application that someone else created (so I don't know the code that well yet) and have run into a problem when the application closes. I get a "User Breakpoint" in the function _CrtIsValidHeapPointer() during the scalar destruction of my CView class and the message HEAP[D32v2.exe]: Invalid Address specified to RtlValidateHeap( 00320000, 00ED011C ) shows up in the output console.
As suggested numerously by many different forums, I have tried both "Multithreaded DLL" as well as "Multithreaded Debug DLL" for the Runtime Library, but the problem still persists.
I have also been told that deleting a pointer twice could also cause the problem. Is there anything else I should look for in the code that could cause this problems?
There is alot of code to go through to solve this problem, so I'd greatly appreciate any help you could give.
Thanks.
 Reply With Quote
-
September 29th, 2004, 10:52 AM#2
Banned 
- Join Date
- Sep 2002
- Location
- Maryland - Fear The Turtle!
- Posts
- 7,537
Re: What causes "Invalid Address specified to RtlValidateHeap"?
Well a couple of things.
1. Set a data breakpoint on 0x00ED011C (that is the invalid address being passed) so that your debugger breaks everytime that address is changed.
2. You know it is happening in the dtor of the CView so you must be looking at a stack trace which means your probably using a debugger, use the debugger to determine what the problem is. (view the call stack and walk backup up the stack to the point of your code)
Is it a double delete? Is it a stray pointer?
Reply With Quote
-
September 29th, 2004, 11:53 AM#3
Member
- Join Date
- Feb 2004
- Location
- Seattle, USA
- Posts
- 137
Re: What causes "Invalid Address specified to RtlValidateHeap"?
Thanks mick for your help.
This is a small portion of the stack trace at the breakpoint:
Code:
> msvcr71d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x00ef013c) Line 1807 C
msvcr71d.dll!_free_dbg_lk(void * pUserData=0x00ef013c, int nBlockUse=12582916) Line 1132 + 0x9 C
msvcr71d.dll!_free_dbg(void * pUserData=0x00ef013c, int nBlockUse=12582916) Line 1070 + 0xd C
mfc71d.dll!CObject::operator delete(void * p=0x00ef013c) Line 45 + 0xf C++
D32v2.exe!CPa32View::`scalar deleting destructor'() + 0x27 C++
There's not much going on besides usual destruction stuff. Delete was called by CView::PostNcDestroy(). PostNcDestroy() calls "delete this". Should this work if my CView class wasn't dynamically allocated?
I put a breakpoint like you suggested at 0x00ED011C and the debugger never broke. Why is it testing 0x00EF011C when 0x00EF013C is being passed to _CrtIsValidHeapPointer?
I also put a breakpoint on 0x00EF013C (the pointer to CPa32View, my CView class) but I didn't notice anything out of the ordinary. Only altered during construction and deletion.
Reply With Quote
-
September 29th, 2004, 12:15 PM#4
MemberPower Poster
- Join Date
- Sep 2002
- Location
- 14° 39'19.65"N / 121° 1'44.34"E
- Posts
- 9,815
Re: What causes "Invalid Address specified to RtlValidateHeap"?
 Originally Posted by enfekted
PostNcDestroy() calls "delete this". Should this work if my CView class wasn't dynamically allocated?
Of course not - this is most probably the cause of your problem. How is the view created if not dynamically? The normal creation process within the doc/view framework always creates views dynamically, and there shouldn't be any reason to do it differently.
Guido Stercken-Sorrenti
Reply With Quote
-
September 29th, 2004, 12:24 PM#5
Banned
- Join Date
- Sep 2002
- Location
- Maryland - Fear The Turtle!
- Posts
- 7,537
Re: What causes "Invalid Address specified to RtlValidateHeap"?
Originally Posted by enfekted
Thanks mick for your help.
I put a breakpoint like you suggested at 0x00ED011C and the debugger never broke. Why is it testing 0x00EF011C when 0x00EF013C is being passed to _CrtIsValidHeapPointer?
I also put a breakpoint on 0x00EF013C (the pointer to CPa32View, my CView class) but I didn't notice anything out of the ordinary. Only altered during construction and deletion.
I see gstercken has address your first part. So I'll take the second 
Probably because you either took a different path in your test or added code to your program which changed memory locations. Do not add code or deviate from a code path when testing failures and setting breakpoints on memory locations.
Reply With Quote
-
September 29th, 2004, 01:03 PM#6
Member
- Join Date
- Feb 2004
- Location
- Seattle, USA
- Posts
- 137
Re: What causes "Invalid Address specified to RtlValidateHeap"?
Thanks gstercken. There is no Doc/View architecture. The view was created in CMainFrame::OnCreate() and is stored in CMainFrame. The VC wizard does it this way when you specify that you don't want a Doc/View architecture.
I just created another app to test it out and found that the view should have been deleted in ~CMainFrame(), not CView::PostNcDestroy().
This is the CallStack from the incorrectly destructing Application:
Code:
mfc71d.dll!CObject::operator delete(void * p=0x00ef013c) Line 45 + 0xf C++
D32v2.exe!CPa32View::`scalar deleting destructor'() + 0x27 C++
mfc71d.dll!CView::PostNcDestroy() Line 120 + 0x1f C++
mfc71d.dll!CWnd::OnNcDestroy() Line 848 C++
mfc71d.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012efb8) Line 2023 C++
mfc71d.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x00ef013c, HWND__ * hWnd=0x003702b6, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x003702b6, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71d.dll!AfxWndProcBase(HWND__ * hWnd=0x003702b6, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d48709()
user32.dll!77d4d297()
user32.dll!77d70494()
user32.dll!77d4b368()
user32.dll!77d70494()
user32.dll!77d4e639()
ntdll.dll!7c90eae3()
user32.dll!77d4e672()
mfc71d.dll!CWnd::DestroyWindow() Line 988 + 0xd C++
mfc71d.dll!CFrameWnd::OnClose() Line 851 C++
D32v2.exe!CMainFrame::OnClose() Line 165 C++
mfc71d.dll!CWnd::OnWndMsg(unsigned int message=16, unsigned int wParam=0, long lParam=0, long * pResult=0x0012f330) Line 2023 C++
mfc71d.dll!CWnd::WindowProc(unsigned int message=16, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x00ef0068, HWND__ * hWnd=0x00380334, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x00380334, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71d.dll!AfxWndProcBase(HWND__ * hWnd=0x00380334, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d56e46()
user32.dll!77d70494()
user32.dll!77d4b368()
user32.dll!77d70494()
user32.dll!77d4b3b4()
ntdll.dll!7c90eae3()
user32.dll!77d494e3()
user32.dll!77d4b2d5()
user32.dll!77d484bc()
user32.dll!77d4b8b6()
user32.dll!77d484bc()
user32.dll!77d48564()
user32.dll!77d4e010()
uxtheme.dll!5ad73c20()
uxtheme.dll!5ad8e300()
uxtheme.dll!5ad71ac7()
uxtheme.dll!5ad7367a()
uxtheme.dll!5ad8e2d5()
user32.dll!77d4e02b()
user32.dll!77d70494()
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d70494()
user32.dll!77d4c00e()
user32.dll!77d4e366()
mfc71d.dll!CWnd::DefWindowProcA(unsigned int nMsg=1243040, unsigned int wParam=2082654585, long lParam=274) Line 1024 + 0x20 C++
mfc71d.dll!CThreadLocal<_AFX_THREAD_STATE>::GetData() Line 177 + 0xd C++
And here is the call stack from a working App at the deletion of the CView object:
Code:
>> mfc71d.dll!CObject::~CObject() Line 23 C++
mfc71d.dll!CCmdTarget::~CCmdTarget() Line 53 + 0xf C++
mfc71d.dll!CWnd::~CWnd() Line 764 + 0xf C++
TestApp.exe!CChildView::~CChildView() Line 21 + 0x8 C++
TestApp.exe!CMainFrame::~CMainFrame() Line 41 + 0xe C++
TestApp.exe!CMainFrame::`scalar deleting destructor'() + 0x2b C++
mfc71d.dll!CFrameWnd::PostNcDestroy() Line 213 + 0x1f C++
mfc71d.dll!CWnd::OnNcDestroy() Line 848 C++
mfc71d.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012efc8) Line 2023 C++
mfc71d.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x00322d70, HWND__ * hWnd=0x00150400, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x00150400, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71d.dll!AfxWndProcBase(HWND__ * hWnd=0x00150400, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d48709()
user32.dll!77d4d297()
user32.dll!77d70494()
user32.dll!77d4b368()
user32.dll!77d70494()
user32.dll!77d4e639()
ntdll.dll!7c90eae3()
user32.dll!77d4e672()
mfc71d.dll!CWnd::DestroyWindow() Line 988 + 0xd C++
mfc71d.dll!CFrameWnd::OnClose() Line 851 C++
mfc71d.dll!CWnd::OnWndMsg(unsigned int message=16, unsigned int wParam=0, long lParam=0, long * pResult=0x0012f330) Line 2023 C++
mfc71d.dll!CWnd::WindowProc(unsigned int message=16, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++
mfc71d.dll!AfxCallWndProc(CWnd * pWnd=0x00322d70, HWND__ * hWnd=0x00150400, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++
mfc71d.dll!AfxWndProc(HWND__ * hWnd=0x00150400, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 389 C++
mfc71d.dll!AfxWndProcBase(HWND__ * hWnd=0x00150400, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d56e46()
user32.dll!77d70494()
user32.dll!77d4b368()
user32.dll!77d70494()
user32.dll!77d4b3b4()
ntdll.dll!7c90eae3()
user32.dll!77d494e3()
user32.dll!77d4b2d5()
user32.dll!77d484bc()
user32.dll!77d4b8b6()
user32.dll!77d484bc()
user32.dll!77d48564()
user32.dll!77d4e010()
uxtheme.dll!5ad73c20()
uxtheme.dll!5ad8e300()
uxtheme.dll!5ad71ac7()
uxtheme.dll!5ad7367a()
uxtheme.dll!5ad8e2d5()
user32.dll!77d4e02b()
user32.dll!77d70494()
user32.dll!77d48709()
user32.dll!77d487eb()
user32.dll!77d70494()
user32.dll!77d4c00e()
user32.dll!77d4e366()
mfc71d.dll!CWnd::DefWindowProcA(unsigned int nMsg=1243040, unsigned int wParam=2082654585, long lParam=274) Line 1024 + 0x20 C++
mfc71d.dll!CThreadLocal<_AFX_THREAD_STATE>::GetData() Line 177 + 0xd C++
Notice in the working application ~CChildView is being called from ~CMainFrame, but in the non-working application "CPa32View: perator delete" is being called from PostNcDestroy(). (btw, CPa32View is the Child view in my app)
Thanks for your help. Got any ideas?
Reply With Quote
-
September 29th, 2004, 01:20 PM#7
Member
- Join Date
- Feb 2004
- Location
- Seattle, USA
- Posts
- 137
Re: What causes "Invalid Address specified to RtlValidateHeap"?
OHHH!!!
CPa32View isn't supposed to be derrived from CView! Its supposed to be derrived from CWnd. Weird. What a messed up program!
Thanks alot for your help.
Reply With Quote
-
September 29th, 2004, 01:43 PM#8
MemberPower Poster
- Join Date
- Sep 2002
- Location
- 14° 39'19.65"N / 121° 1'44.34"E
- Posts
- 9,815
Re: What causes "Invalid Address specified to RtlValidateHeap"?
Originally Posted by enfekted
CPa32View isn't supposed to be derrived from CView! Its supposed to be derrived from CWnd. Weird. What a messed up program!
Yes. While you posted this, I was still wondering how there could be a view created by AppWizard if doc/view was not selected. Actually, without doc/view, you just get a generic CWnd generated.
Guido Stercken-Sorrenti
Reply With Quote
Qui
|
