使用CComVariant时Outlook插件内存泄漏

Question

我正在分析Outlook插件中的句柄泄漏和内存泄漏。

我将分析步骤放在这里，因为我几乎没有任何c ++知识（上次使用c ++的时间是7年前）。

从Google搜索之后，我使用WinDbg的！htrace -diff命令来查找句柄泄漏。 另外，我使用umdh来获得内存差异。

通过比较2个结果，我发现有很多相同的调用堆栈似乎对两者都有贡献：

这是处理差异信息：

0x77ce55f4: ntdll!NtCreateEvent+0x0000000c
0x75d978a6: KERNELBASE!CreateEventExW+0x0000006e
0x75d97926: KERNELBASE!CreateEventExA+0x00000035
0x75d97965: KERNELBASE!CreateEventA+0x00000027
0x6740738b: olmapi32!HrLogAndRunFnOnThreadEx+0x000002c4
0x67407295: olmapi32!HrLogAndRunFnOnThreadEx+0x000001ce
0x674075cf: olmapi32!HrLogAndRunFnOnThreadEx+0x00000508
0x6740758e: olmapi32!HrLogAndRunFnOnThreadEx+0x000004c7
0x6741cfb2: olmapi32!REFTRACK_WrapObject+0x00000b30
0x6741cf37: olmapi32!REFTRACK_WrapObject+0x00000ab5
0x6741ce55: olmapi32!REFTRACK_WrapObject+0x000009d3
0x67421ed2: olmapi32!HrAsyncWrapObject+0x0000005a

这是内存差异信息

ntdll!EtwSetMark+23ED
ntdll!RtlInitializeCriticalSectionEx+12B
ntdll!RtlInitializeCriticalSection+12
olmapi32!MSProviderInit+D9
olmapi32!MSProviderInit+1D
olmapi32!REFTRACK_AddRefEx+113
olmapi32!REFTRACK_WrapObject+CDE
olmapi32!REFTRACK_WrapObject+BF1
olmapi32!REFTRACK_WrapObject+AC9
olmapi32!REFTRACK_WrapObject+9D3
olmapi32!HrAsyncWrapObject+5A
olmapi32!FBadEntryList+BF
OUTLOOK!FOutlookIsDeepSyncing+D045
OUTLOOK!FOutlookIsDeepSyncing+CD1D
OUTLOOK!FOutlookIsDeepSyncing+CA93
OUTLOOK!FAllowStoreToSend+1A543
OUTLOOK!GetCurrentDate+9733B
OUTLOOK!HrEnsureIMManager+49BC
OUTLOOK!HrEnsureIMManager+3C75
OUTLOOK!GetMsoInst+2E76
OUTLOOK!GetMsoInst+5BCB
OUTLOOK!GetMsoInst+5C7A
OUTLOOK!HrFindAContact+1893F
DCO!OOM::Items::add+102 (C:\XXX\item.cpp, 67)
....

最后，在item.cpp第67行中，我发现

Item Items::add( const std::wstring& type ) const
{
    IDispatchPtr pIItem = NULL;
    HRESULT hr = getImpl()->Add( CComVariant(type.c_str()), &pIItem );    <<< Line 67
    if ( FAILED(hr) )
        throw Exception( hr, this, L"_Items::Add" );
    return Item( pIItem );
}

我在Google上搜索了更多，并且知道getImpl（）是SmartPointer的功能。 CComVariant是用来包装对象的东西。 我在CComVariant上搜索了一些内存泄漏示例，但是这种情况似乎并不相同。

是否知道该代码会导致句柄/内存泄漏？ 或有任何建议我可以做更多研究吗？

提前致谢。

Answer 1

经过2周的调查，我认为我找到了根本原因，正如WhozCraig怀疑的那样，根本原因是AddRef（）和Release（）不匹配。

错误代码非常简单：

_variant_t vtUnk = dispatch_adapter::get(getImpl(), L"MAPIOBJECT");
CComPtr<IUnknown> pIUnk((IUnknown*)vtUnk);

为了研究这个问题，我研究了一些源代码，第一个是_variant_t

// Extracts a VT_UNKNOWN into an IUnknown*
//
inline _variant_t::operator IUnknown*() const 
{
    if (V_VT(this) == VT_UNKNOWN) {
        if (V_UNKNOWN(this) != NULL) {
            V_UNKNOWN(this)->AddRef();    // Here Added Ref
        }
        return V_UNKNOWN(this);
    }

    _variant_t varDest;
    varDest.ChangeType(VT_UNKNOWN, this);

    if (V_UNKNOWN(&varDest) != NULL) {
        V_UNKNOWN(&varDest)->AddRef();    // Here Added Ref
    }

    return V_UNKNOWN(&varDest);
}

然后，如果我们查看CComPtr的构造函数，则会发现：

CComPtr( T* lp) {if((p=lp)!=NULL) p->AddRef();}; // Here Add Ref Again.

两次AddRef（），仅一次Release（），这就是为什么发生句柄/内存泄漏的原因。

为了解决这个问题，我们可以使用CComPtr.Attach()代替CComPtr的构造函数。