Управляемая утечка памяти в C ++ - PullRequest
Новая
       20

Управляемая утечка памяти в C ++

1 голос
/ 13 августа 2010

Я получаю утечку памяти всякий раз, когда новый поток RPC на сервере DCOM (сервер c ++ DCOM) вызывает следующий управляемый метод C ++ 

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

Я получаю указатель управляемого объекта C ++ с использованиемкод floowing 

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);
}

Вот так я вызываю управляемый вызов в части C ++ сервера DCOME 

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

Приведенный ниже стек вызовов указывает местоположение памятиутечкаЕсть ли способы решить эту утечку памяти?Пожалуйста, помогите мне 

 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

1 Ответ

0 голосов
/ 14 августа 2010

Во-первых, LotActive это переменная / поле элемента (чистые данные) или свойство?

Я думаю, что это свойство, и прежде чем его можно будет установить, JIT должен скомпилировать код для установщика. В настольном .NET нативный код, созданный процессом JIT-компиляции, не является сборщиком мусора, он существует в течение всего срока службы домена приложений, поэтому может выглядеть как утечка.

Можете ли вы проверить, протекает ли каждый вызов этой функции другого объекта, или утечка происходит только один раз?

...