托管C ++内存泄漏 [英] Managed C++ Memory leak

问题描述

当DCOM服务器（c ++ DCOM服务器）中的新RPC线程调用以下托管C ++方法时，我会遇到内存泄漏

I am getting a memory leak whenver a new RPC thread in a DCOM server (c++ DCOM server) invokes the following managed C++ method

void CToolDataClient::SetLotManagerActive(bool bLotManagerActive)
{
  if( m_toolDataManager != nullptr)
  {
   m_toolDataManager->LotActive = bLotManagerActive;
  }
}

---

我使用floowing代码获得托管的C ++对象指针。

---

I get the managed C++ object pointer using the floowing code

typedef bool (*FPTR_CREATEINTERFACE)(CToolDataInterface ** ppInterface);

FPTR_CREATEINTERFACE fnptr = (FPTR_CREATEINTERFACE)GetProcAddress(hModule,(LPTSTR)"CreateInstance");
if ( NULL != fnptr ) 
{
  CICELogger::Instance()->LogMessage("CToolDataManager::CToolDataManager", Information, 
            "Created instance of DataManagerBridge");
  fnptr(&m_pToolDataInterface);
}

---

DCOME服务器中的托管调用C ++部分

---

This is how I invoke the managed call in the DCOME server C++ portion

void CToolDataManager::SetLotManagerActive(bool bLotManagerActive)
{
    if(m_pToolDataInterface != NULL)
    {
        m_pToolDataInterface->SetLotManagerActive(bLotManagerActive);
    }
}

---

下面给出的callstack指示内存泄漏的位置。有没有办法解决这个内存泄漏？请帮助我

---

The callstack given below indicate the location of the memory leak . Is there any ways to solve this memory leak? Please help me

 ntdll!RtlDebugAllocateHeap+000000E1
 ntdll!RtlAllocateHeapSlowly+00000044
 ntdll!RtlAllocateHeap+00000E64
 mscorwks!EEHeapAlloc+00000142
 mscorwks!EEHeapAllocInProcessHeap+00000052
 **mscorwks!operator new[]+00000025
 mscorwks!SetupThread+00000238
 mscorwks!IJWNOADThunk::FindThunkTarget+00000019
 mscorwks!IJWNOADThunkJumpTargetHelper+0000000B
 mscorwks!IJWNOADThunkJumpTarget+00000048
 ICEScheduler!CToolDataManager::SetLotManagerActive+00000025** (e:\projects\ice\ice_dev\trunk\source\application source\iceschedulersystem\icescheduler\tooldatamanager.cpp, 250)
 ICEScheduler!SetLotManagerActive+00000014 (e:\projects\ice\ice_dev\trunk\source\application source\iceschedulersystem\icescheduler\schddllapi.cpp, 589)
 ICELotControl!CLotDetailsHandler::SetLotManagerStatus+0000006C (e:\projects\ice\ice_dev\source\application source\icelotsystem\icelotcontrol\lotdetailshandler.cpp, 1823)
 ICELotControl!CLotManager::StartJob+00000266 (e:\projects\ice\ice_dev\source\application source\icelotsystem\icelotcontrol\lotmanager.cpp, 205)
 RPCRT4!Invoke+00000030
 RPCRT4!NdrStubCall2+00000297
 RPCRT4!CStdStubBuffer_Invoke+0000003F
 OLEAUT32!CUnivStubWrapper::Invoke+000000C5
 ole32!SyncStubInvoke+00000033
 ole32!StubInvoke+000000A7
 ole32!CCtxComChnl::ContextInvoke+000000E3
 ole32!MTAInvoke+0000001A
 ole32!AppInvoke+0000009C
 ole32!ComInvokeWithLockAndIPID+000002E0
 ole32!ThreadInvoke+000001CD
 RPCRT4!DispatchToStubInC+00000038
 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+00000113
 RPCRT4!RPC_INTERFACE::DispatchToStub+00000084
 RPCRT4!RPC_INTERFACE::DispatchToStubWithObject+000000C0
 RPCRT4!LRPC_SCALL::DealWithRequestMessage+000002CD
 RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0000016D
 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0000028F

推荐答案

首先是 LotActive 变量/字段（纯数据）或属性？

First, is LotActive a member variable/field (pure data) or a property?

我认为它是一个属性，在它可以设置之前，JIT必须编译代码设置器。在桌面.NET中，由JIT编译过程生成的本地代码不是垃圾收集，而是存在于AppDomain的生命周期中，因此它可能看起来像泄漏。

I think that it is a property, and before it can be set, the JIT has to compile the code for the setter. In desktop .NET, native code produced by the JIT compilation process is not garbage collected, instead it exists for the lifetime of the AppDomain, so it could look like a leak.

你可以检查每个调用这个函数是否泄漏另一个对象，或者泄漏只发生一次？

Can you check whether each call to this function leaks another object, or the leak just occurs once?

这篇关于托管C ++内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！