Euromuffin
asked on
Frame window memory leaks
In case anyone has a quick answer:
When I use CFrameWnd::Create to open a frame window, and then close it via its Close button, why does this lead to unfreed memory allocated in the following areas:
CWnd::CreateObject, CPlex::Create, CPlex::Create, CMapPtrToPtr::InitHashTabl e, CMapPtrToPtr::InitHashTabl e, CString::AllocBuffer, <unknown>, CMenu::CreateObject, CMenu::CreateObject
Otherwise, here's a detailed explanation of my problem:
I am trying to track down a memory leak using a test app under VC5 and with the help of BoundsChecker 6.2. After building a debug version of the code using VC5, I run it with BC integrated debugging enabled. It is a simple SDI app with a couple menu options and the following two handlers for them:
void CMainFrame::OnViewNewframe ()
{
CFrameWnd *pframe = new CFrameWnd;
pframe->Create(NULL, "test frame", WS_OVERLAPPEDWINDOW | WS_VISIBLE);
}
void CMainFrame::OnViewCheckmem ory()
{
static int i = 0;
if (i == 0)
{
OpenMutex(MUTEX_ALL_ACCESS ,TRUE,"bog usmutex");
i++;
return;
}
if (i == 1)
{
OpenMutex(MUTEX_ALL_ACCESS ,TRUE,"bog usmutex");
i++;
return;
}
if (i == 2)
{
OpenMutex(MUTEX_ALL_ACCESS ,TRUE,"bog usmutex");
i++;
return;
}
}
I first select the View|Check Memory option, which causes a deliberate error to be detected by BC so that I can access its Mark Memory option.
I then select the View|New Frame option, which does nothing more than open a simple CFrameWnd by calling its Create member. I then close the frame.
Finally, I select View|Check Memory again to cause another deliberate error so that I can determine all instances of memory allocated but unfreed since I did Mark Memory. This results in the above list.
Anyone know why these leaks are happening and how to get rid of them? TIA.
When I use CFrameWnd::Create to open a frame window, and then close it via its Close button, why does this lead to unfreed memory allocated in the following areas:
CWnd::CreateObject, CPlex::Create, CPlex::Create, CMapPtrToPtr::InitHashTabl
Otherwise, here's a detailed explanation of my problem:
I am trying to track down a memory leak using a test app under VC5 and with the help of BoundsChecker 6.2. After building a debug version of the code using VC5, I run it with BC integrated debugging enabled. It is a simple SDI app with a couple menu options and the following two handlers for them:
void CMainFrame::OnViewNewframe
{
CFrameWnd *pframe = new CFrameWnd;
pframe->Create(NULL, "test frame", WS_OVERLAPPEDWINDOW | WS_VISIBLE);
}
void CMainFrame::OnViewCheckmem
{
static int i = 0;
if (i == 0)
{
OpenMutex(MUTEX_ALL_ACCESS
i++;
return;
}
if (i == 1)
{
OpenMutex(MUTEX_ALL_ACCESS
i++;
return;
}
if (i == 2)
{
OpenMutex(MUTEX_ALL_ACCESS
i++;
return;
}
}
I first select the View|Check Memory option, which causes a deliberate error to be detected by BC so that I can access its Mark Memory option.
I then select the View|New Frame option, which does nothing more than open a simple CFrameWnd by calling its Create member. I then close the frame.
Finally, I select View|Check Memory again to cause another deliberate error so that I can determine all instances of memory allocated but unfreed since I did Mark Memory. This results in the above list.
Anyone know why these leaks are happening and how to get rid of them? TIA.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: ShaunWilde
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Roshan Davis
EE Cleanup Volunteer