The MSDN documentation for the CCmdTarget::OnFinalRelease method is pretty brief:
Called by the framework when the last OLE reference to or from the
object is released.
I have created a sub-class of CCmdTarget
class CMyEventHandler : public CCmdTarget { ... }
I'm trying to figure out under what conditions the OnFinalRelease method will be called. I have some code that looks something like this:
CMyEventHandler* myEventHandler = new CMyEventHandler();
LPUNKNOWN pUnk = myEventHandler->GetIDispatch(FALSE);
AfxConnectionAdvise(myEventSource, DIID_IMyEventInterface, pUnk, FALSE, myCookie);
// Application continues...events arrive...eventually the event sink is shutdown
LPUNKNOWN pUnk = myEventHandler->GetIDispatch(FALSE);
AfxConnectionUnadvise(myEventSource, DIID_IMyEventInterface, pUnk, FALSE, myCookie);
Using this code, I observe that the OnFinalRelease method is never called. This means I have a memory leak. So I modified the wrap-up code as follows:
LPUNKNOWN pUnk = myEventHandler->GetIDispatch(FALSE);
AfxConnectionUnadvise(myEventSource, DIID_IMyEventInterface, pUnk, FALSE, myCookie);
delete myEventHandler;
myEventHandler = NULL;
This section of code is triggered off periodically throughout the day. What I notice now is that, while the destructor for the wrapped up instance of myEventHandler is called as expected, the OnFinalRelease function is getting called now! What's worse, it is being called not on the instance that has been wrapped up, but instead on a newly created instance of CMyEventHandler! Thinking that this might be due to a reference counting issue, I modified my wire-up and wrap-up code:
CMyEventHandler* myEventHandler = new CMyEventHandler();
LPUNKNOWN pUnk = myEventHandler->GetIDispatch(TRUE);
AfxConnectionAdvise(myEventSource, DIID_IMyEventInterface, pUnk, TRUE, myCookie);
pUnk->Release();
// Application continues...events arrive...eventually the event sink is shutdown
LPUNKNOWN pUnk = myEventHandler->GetIDispatch(TRUE);
AfxConnectionUnadvise(myEventSource, DIID_IMyEventInterface, pUnk, TRUE, myCookie);
pUnk->Release();
delete myEventHandler;
myEventHandler = NULL;
I let this run all day and now observe that OnFinalRelease is never called. The destructor for the wrapped up instance is called as I would expect, but I'm left feeling uneasy as I clearly don't understand the circumstances under which OnFinalRelease is called. Is OnFinalRelease called on some delay, or is there a way to force it to fire? What will trigger OnFinalRelease to be called?
If it matters, the event source is a .NET assembly exposing events via COM interop.
With COM you should always use the CoCreateInstance() AddRef() and Release() paradigm to manage lifetime of your objects, and let COM do the destruction of your objects based on reference counts. Avoid new and delete because using them breaks this paradigm and causes interesting side effects. You probably have a bug in the management of the reference counts.
The way to debug why the reference counts are not being managed correctly is to override CCmdTarget::InternalRelease() copy the source from oleunk.cpp and put some trace output or break points.
DWORD CMyEventHandler::InternalRelease()
{
ASSERT(GetInterfaceMap() != NULL);
if (m_dwRef == 0)
return 0;
LONG lResult = InterlockedDecrement(&m_dwRef);
if (lResult == 0)
{
AFX_MANAGE_STATE(m_pModuleState);
OnFinalRelease();
}
return lResult;
}
There are lots of times when passing IDispatch interfaces that code will bump reference counts and you have to decrement the reference count using Release(). Pay attention to where your code may be passing this interface because there is aconvention in COM that when Interfaces are passed using [in] or [out] where the caller or callee has to release the interface.
When the reference count issue is corrected you shoudl see the objects OnFinalRelease code being called and the object destoryed by hte MFC framework:
For CCmdTarget the destruction should happen as a result of the final
release in the parent class CWnd:
void CWnd::OnFinalRelease()
{
if (m_hWnd != NULL)
DestroyWindow(); // will call PostNcDestroy
else
PostNcDestroy();
}
FYI: Passing interfaces across threads without marshalling the interface pointers is another common reason to get errors in COM.
It doesn't appear that you ever call myEventHandler->Release(). Therefore, the last reference is never released, and OnFinalRelease is never called.
Related
I'm debugging an intermittent issue on a customer site. I've got it down to the point that it appears that a call to Release() on a COM object is not returning.
The first log is printing but I never see the second log. I can only assume that the call to Release() never returned for some reason (or could it be the CoInitializeEx()).
I have no idea what to look for next, any help/clues would be greatly appreciated.
Logger::getLogger()->logTrace("AudioCapturer::_shutdown. _pEndpointAudioClient_COM Released. (%s)", _deviceName.c_str());
releaseComObject(_pAudioCaptureClient_COM);
Logger::getLogger()->logTrace("AudioCapturer::_shutdown (%s) succeeded", _deviceName.c_str());
Here is the supporting code:
IAudioCaptureClient *_pAudioCaptureClient_COM;
// Class that Initializes COM on creation and Unitializes on destruction
AutoCOM::AutoCOM() { CoInitializeEx(NULL, COINIT_MULTITHREADED); }
AutoCOM::~AutoCOM() { CoUninitialize(); }
#define AUTO_COM_SUPPORT AutoCOM _autoCOM
// Safe releasing of COM objects. Zeros the pointer
// to the COM object. Safe to use with NULL
// pointers.
template <class T> void releaseComObject(T*& pT) {
if (pT) {
AUTO_COM_SUPPORT;
(pT)->Release();
pT = NULL;
}
}
Never found a duplication scenario for the issue. But the problem was averted with the user of smart pointers, which was mentioned by #Cheersandhth.-Alf. Thanks for the feedback.
Basically used the following macro to define smart pointers, and removed all references to Release()
_COM_SMARTPTR_TYPEDEF(IMyInterface, __uuidof(IMyInterface));
The documentation states that InternetOpen can be called multiple times without any issues. My question though is should I be calling InternetCloseHandle on handle returned by it multiple times?
For example, I have a class I call CAPIRequestContext, which has a handle which is returned by InternetOpen. Each one of my requests has it's own copy. Right now, I call InternetCloseHandle in the destructor, so it gets called multiple times.
I'm wondering if the following could cause issues:
Thread A creates a CAPIRequestObject which calls InternetOpen and stores the handle. Thread B does the same, but then goes out of scope before Thread A exits, so Thread B calls the destructor in it's own CAPIRequestObject, which calls InternetCloseHandle on the handle returned by InternetOpen.
Should I remove the call to InternetCloseHandle in the destructors of my class? At least for the InternetHandle? I assume I should call InternetCloseHandle for the handle returned by HttpOpenRequest.
I have similar questions regarding the handle returned by InternetConnect. Are these handles shared?
Here is some sample code, minus some external code that I don't think is related to the issue:
class CAPIClient;
class CAPIRequest
{
public:
CAPIRequestContext()
{
m_hConn = NULL;
m_hInternet = NULL;
m_hRequest = NULL;
}
~CAPIRequestContext()
{
if (m_hRequest) InternetCloseHandle(m_hRequest);
if (m_hConn) InternetCloseHandle(m_hConn);
if (m_hInternet) InternetCloseHandle(m_hInternet);
}
bool Init(const CAPIClient &client, const std::string &uri, const std::string &method)
{
ATLASSERT(!(m_hInternet || m_hConn || m_hRequest));
if (m_hInternet || m_hConn || m_hRequest) throw std::exception("Cannot init request more than once.");
bool success = false;
m_AuthToken = *client.m_pAuthToken;
URI = uri;
m_hInternet = InternetOpen("MyApp", INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);
DWORD requestTimeout = 60 * 1000; // Set timeout to 60 seconds instead of 30
if (m_hInternet)
{
InternetSetOption(m_hInternet, INTERNET_OPTION_RECEIVE_TIMEOUT, &requestTimeout, sizeof(requestTimeout));
m_hConn = InternetConnect(m_hInternet, (LPSTR)client.m_host.c_str(), client.m_port, NULL, NULL, INTERNET_SERVICE_HTTP, 0, (DWORD_PTR)this);
if (m_hConn) {
m_hRequest = HttpOpenRequest(m_hConn, method.c_str(), uri.c_str(), "HTTP/1.1", NULL, NULL, client.GetOpenRequestFlags(), 0);
}
if (m_hRequest)
{
success = true;
}
}
return success;
}
}
// There are additional calls like
// SendRequest
// GetData
// GetFullResponse
private:
// Added these methods to make sure I'm not copying the handles
enter code here
CAPIRequestContext(const CAPIRequestContext &other) = delete;
CAPIRequestContext& operator=(const CAPIRequestContext& other) = delete;
private:
HINTERNET m_hInternet;
HINTERNET m_hConn;
HINTERNET m_hRequest;
}
The documentation states that InternetOpen can be called multiple times without any issues. My question though is should I be calling InternetCloseHandle on handle returned by it multiple times?
Yes, as is stated in InternetOpen() documentation:
After the calling application has finished using the HINTERNET handle returned by InternetOpen, it must be closed using the InternetCloseHandle function.
For example, I have a class I call CAPIRequestContext, which has a handle which is returned by InternetOpen. Each one of my requests has it's own copy. Right now, I call InternetCloseHandle in the destructor, so it gets called multiple times.
That would be a correct implementation, if each instance of the class calls InternetOpen(), or otherwise obtains ownership of a unique HINTERNET.
HOWEVER, do be aware that such a class needs to implement the Rule of Three. Basically, if you have to provide a destructor to release a resource, you also need to provide a copy-constructor and copy-assignment operator as well.
But, you can't call InternetCloseHandle() multiple times on the same HINTERNET, so you can't have multiple CAPIRequestContext using the same HINTERNET and all of them calling InternetCloseHandle()1. So, your copy constructor and copy-assignment operator must either:
take ownership of the HINTERNET from the source CAPIRequestContext that is being copied.
be disabled completely to prevent copying one CAPIRequestContext to another.
In your case, I would opt for #2.
1: You would need a per-instance flag indicating which instance can call it and which ones cannot. But this is not good class design. If you need to share an HINTERNET, you should implement reference counting semantics instead, such as provided by std::shared_ptr.
I'm wondering if the following could cause issues: Thread A creates a CAPIRequestObject which calls InternetOpen and stores the handle. Thread B does the same, but then goes out of scope before Thread A exits, so Thread B calls the destructor in it's own CAPIRequestObject, which calls InternetCloseHandle on the handle returned by InternetOpen.
That is perfectly safe, provided each CAPIRequestObject has its own HINTERNET.
Should I remove the call to InternetCloseHandle in the destructors of my class?
No, if each class instance holds a unique HINTERNET.
I assume I should call InternetCloseHandle for the handle returned by HttpOpenRequest.
Yes, as is stated in the HttpOpenRequest() documentation:
After the calling application has finished using the HINTERNET handle returned by HttpOpenRequest, it must be closed using the InternetCloseHandle function.
I have similar questions regarding the handle returned by InternetConnect. Are these handles shared?
Each HINTERNET must be closed individually.
My program has a callback function which is called to handle notifications that are received in the form of objects. Because we can handle hundreds a second, this callback function handles the events by spawning a separate thread to handle each one. This is the callback function:
void _OnEvent(LPCTSTR eventID, CNotification cNotificaton) {
if (_pActiveDoc) {
Param_Event* p = new Param_Event;
p->pDoc = _pActiveDoc;
p->lpszEventID = eventID;
p->cNotification = cNotification;
AfxBeginThread(ProcessEvent,p);
}
}
My query comes from the fact that is passed to the callback method is initially created on the stack, and is therefore (according to my understanding) limited to the scope of the calling method:
void CallingMethod(CString strEventID) {
CNotification cNotification;
// Fill in the details of the notification
_OnEvent(strEventID,cNotification);
}
CNotification has a full copy constructor, and since the Param_Event object is created on the heap, my belief was that this would allow the original CNotification object to fall out of scope safely, with the spawned thread working from its own "private" CNotification object that exists until the Param_Event object is deleted with delete. The fact is, however, that we are getting (rare but occasional) crashing, and I am wondering if perhaps my belief here is incorrect: is it possible that the spawned thread is still accessing the original object somehow? If this was the case, this would explain the crashing by the rare occurrence of the object both falling out of scope and being overwritten in memory, thus creating a memory access exception.
Could I be right? Is there anything actually wrong with the method I am using? Would it be safer create the notification object on the heap initially (this would mean changing a lot of our code), or building a new object on the heap to pass to the spawned thread?
For reference, here is my ProcessEvent() method:
Param_TelephoneEvent *p = (Param_TelephoneEvent*)lParam;
p->pDoc->OnTelephoneEvent(p->lpszEventID,p->cNotification);
delete p;
return 0;
All advice welcome. Thanks in advance!
Edit: Copy constructor:
CNotification& CNotification::operator=(const CNotification &rhs)
{
m_eamspeMostRecentEvent = rhs.m_eamspeMostRecentEvent;
m_eamtcsCallStatusAtEvent = rhs.m_eamtcsCallStatusAtEvent;
m_bInbound = rhs.m_bInbound;
strcpy(m_tcExtension , rhs.m_tcExtension);
strcpy(m_tcNumber, rhs.m_tcNumber);
strcpy(m_tcName,rhs.m_tcName);
strcpy(m_tcDDI,rhs.m_tcDDI);
strcpy(m_tcCallID,rhs.m_tcCallID);
strcpy(m_tcInterTelEvent,rhs.m_tcInterTelEvent);
m_dTimestamp = rhs.m_dTimestamp;
m_dStartTime = rhs.m_dStartTime;
m_nCallID = rhs.m_nCallID;
return *this;
}
I found this question, but they aren't using a pointer.
I have a method that my COM method calls that requires a pointer to a bool. This bool is used to cancel the long running process (video recording, if you must know) from the caller.
Can I cast it somehow, but still have VARIANT_BOOL equate to FALSE and vice-versa?
Code
HRESULT YourObject::YourComMethod(VARIANT_BOOL* pVarBool)
{
callYourNonComMethodHere((bool*)pVarBool);
return S_OK;
}
UPDATE
So, I learned that, although you can have COM parameters as pointers, but they serve no purpose. That don't actually reference the pointer from the caller.
So, what I had to do was make a totally separate COM object that is my CancellationToken. Then, in my implementation, I can call token.Cancel(), and then the YourComMethod will have the updated bool, indicating that the long running method should cancel.
I created a sample project to demonstrate how I was able to pass a pointer to a bool, using a wrapping COM object.
https://bitbucket.org/theonlylawislove/so-blocking-com-call/src
VARIANT_BOOL is supposed to be one of two values if done right. VARIANT_TRUE or VARIANT_FALSE. On the off chance some neanderthal doesn't understand that with all the buggy COM code out there I generally assume if it isn't VARIANT_FALSE, then it must be true.
So:
HRESULT YourObject::YourComMethod(VARIANT_BOOL* pVarBool)
{
bool bval = (*pVarBool != VARIANT_FALSE); // do this if pVarBool is [in,out]
// bool bval = false; // otherwise do this if pVarBool is [out] only.
callYourNonComMethodHere(&bval);
*pVarBool = bval ? VARIANT_TRUE : VARIANT_FALSE;
return S_OK;
}
After a little clarification from Matt, I think that is what you were trying to do. Or something likely close to it.
I'm creating a DirectX 11 helper class that looks kind of like this:
#import "DXClass.h" // I have declared the constructor and the other methods here
// All of the DirectX libraries are imported in the header as well
DXClass::DXClass()
{
// Pointers created, etc.
}
DXClass:~DXClass()
{
// Other DirectX objects released
// With an if (bbSRView) {}, the exception still occurs, so bbSRView is not NULL
// bbSRView is a ID3D11ShaderResourceView*
// When the other violation does not occur, one does here:
bbSRView->Release();
bbSRView = NULL;
// More releases
void DXClass::Initialize()
{
SetupDisplay();
// Other initialization that works fine
}
void DXClass::SetupDisplay()
{
// This is where the debugger shows the access violation.
// factory is declared as DXGIFactory*
HRESULT hr = CreateDXGIFactory(__uuidof(IDXGIFactory), (void **)&factory);
// Loop through adapters and outputs, etc.
}
This class is initialized like this: dxClass = new DXClass();
The Initialize() function is called in another method of the class that created dxClass.
When the application is run, I get an access violation at the beginning of the setupDisplay() function. However, if I take the code in setupDisplay() and put it in Initialize(), removing the call to setupDisplay(), no access violation occurs. Also, if I remove the code from setupDisplay() so that it is an empty function, and then call it in Initialize(), no access violation occurs.
It appears that no pointers are NULL, and the application will start fine if it is changed as described above. However, on another note, the application receives another access violation when quitting. The debugger points to a Release() call on an ID3D11ShaderResourceView*, which I have pointed out in my code snippet. This pointer also appears to be valid.
I have also checked the similar questions, but the this pointer of the class appears to be valid, and I am not creating any buffers that could be overflowing. There also isn't anything that could be deleting/freeing the object early.
I have no idea what could be causing the errors. :/
Thanks :D
EDIT:
Here's an isolated test, with the same errors:
I have in my main function:
INT APIENTRY wWinMain(HINSTANCE, HINSTANCE, LPWSTR, INT)
{
App *app = new App();
app->Run();
app->Release();
}
In my App class, I have removed all window functionality and any other variables so that it looks like this:
App::App()
{
dxClass = new DXClass();
}
App::~App()
{
delete dxClass;
}
void App::Run()
{
dxClass->Initialize();
while (true) {} // Never reaches here
}
The access violation still occurs at the same place. Also, same results if I replace the factory instance variable with:
IDXGIFactory *f;
HRESULT hr = CreateDXGIFactory(__uuidof(IDXGIFactory), (void **)&f);
Which has worked for me in other applications.
An access violation when calling Release() usually means the object has already received it's final Release() from somewhere else (and it has destroyed itself). One possible solution would be to AddRef() when passing the pointer into your DXClass