I have once seen someone do something like

class CFile
{
...
        void *operator new() { return ::OpenFile(...) }
        operator delete(void *p) { ::CloseHandle(p) }
...
};

which would make the code you have correct but that does not seem to be your
case (and by the way it is an inflexible maintenance ridden nightmare
construct so don't even think about doing it)

> -----Original Message-----
> From: Phil Beck [mailto:philEF-X.COM]
> Sent: 10 April 2001 14:05
> To: DCOMDISCUSS.MICROSOFT.COM
> Subject: [DCOM] debugging someone's code
>
>
> Hi,
>
> I am making use of an mfc dll that acts as an abstract layer
> between me and
> a dcom exe server. The program seems to work okay until I
> shut it down.
> Then it calls the following function within the dll :-
>
> void CClientApp::WaitShutdownDCOMThread() {
>
> AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
> ::WaitForSingleObject(m_pDCOMThread->m_hThread, 10000); //
> 10 second delay
>
> DWORD dwRetCode;
> if (GetExitCodeThread(m_pDCOMThread->m_hThread, &dwRetCode)
> == FALSE)
> {
> TRACE ("SERIOUS ERROR - failed to find DCOMThread handle\n");
> }
> if (dwRetCode == STILL_ACTIVE)
> {
> TRACE ("WARNING - DCOMThread is hung, using
> TerminateThread (will leak
> memory!)\n");
> ::TerminateThread(m_pDCOMThread->m_hThread, 0) ;
> }
> else
> {
> TRACE ("DCOMThread has terminated - code %d \n", dwRetCode);
> }
>
> delete m_pDCOMThread->m_hThread;
> }
>
> It is the last line. The c++ delete operator appears to be
> getting called
> on a handle. When in debug mode I have seen that the value of that was
> 0x00000204, which looks more likely to be a handle than a
> pointer. The code
> within that delete that ASSERTED was :-
> DbgHeap.C and the ASSERT looked like :-
>
> /*
> * If this ASSERT fails, a bad pointer has been
> passed in. It may be
> * totally bogus, or it may have been allocated from
> another heap.
> * The pointer MUST come from the 'local' heap.
> */
> _ASSERTE(_CrtIsValidHeapPointer(pUserData));
>
>
> Please could anyone tell me if this call of delete on a
> handle looks like
> bad code, or whether the usage is okay and the bug is more
> likely to be
> caused by something else.
>
> Thanks
> Phil.
>

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]