It's clearly by design that the bJustRevoke is passed as TRUE from AfxPostQuitMessage. It's obviously deliberate to skip all the
other cleanup code in this case. My guess is that there had been some sequencing issues that led to crashes during app shutdown, so
it was decided to just bypass some of this unnecessary cleanup. If the app is shutting down, why do you care if that little bit
isn't explicitly released? When the app terminates, all its memory is returned to the OS anyway.
Yeah I am positive it is the bJustRevoke. From the call stack during app
termination, it goes AfxPostQuitMessage - >AfxOleTermOrFreeLib -> AfxOleTerm.
AfxPostQuitMessage source code shows
"(*pThread->m_lpfnOleTermOrFreeLib)(TRUE, TRUE);".
That TRUE value is what goes into bJustRevoke.
Is there a proper way I am supposed to be destructing my app when I called a
Cwnd::CreateControl or is this always supposed to be automatic?
"Goran" wrote:
On Aug 24, 6:08 am, Hash Brown <Hash Br...@discussions.microsoft.com>
wrote:
I am stumped by this one. I've traced the memory leak down to oleinit.cpp
(line 84)
"pthread->m_pMessageFilter = new COleMessageFilter"
Apparently when I call Cwnd::CreateControl, the above line is called to
create this message filter through AfxOleInit(). However during termination
time, the corresponding delete function of AfxOleInit (which seems to be
AfxOleTerm()) is called but doesn't delete the messagefilter because of a
boolean bJustRevoke.
Anyone with expertise in this code knows what's going on??
I don't know, but, are you sure it's about bJustDelete, and not NULL
check on the thread (right after)? (You have to call AfxOleTerm (and
one other MFC function) with bJustTerm set explicitly to TRUE for this
to work this way; I take it that's not what you're doing.)
If it's about the thread, you are too late to get to AfxOleTerm
(thread is already gone), and you have another problem there.
Goran.