new/delete의 짝이 맞는 경우에도 메모리 누수가 발생한다면?
PDB 심볼을 다루다보면 ISymUnmanagedMethod 인터페이스의 GetSequencePoints 메서드를 이용해 ISymUnmanagedDocument 배열을 반환받는 과정이 다음과 같이 펼쳐집니다.
netmf /client_v4_2_comm/CLR/Tools/Parser/Support.cpp
; https://searchcode.com/codesearch/view/11140450/
pOffsets = new ULONG32[cSeqPoints]; // 배열 할당
// ...[생략]...
pDocs = new ISymUnmanagedDocument*[cSeqPoints]; // 배열 할당
// GetSequencePoints 메서드에서 cSeqPoints 개수만큼 할당된 배열에 내용이 채워짐
TINYCLR_CHECK_HRESULT(pMethod->GetSequencePoints( cSeqPoints, &cSeqPoints, pOffsets, pDocs, pLines, pCols, pEndLines, pEndCols ));
for(ULONG32 i = 0; i < cSeqPoints; i++)
{
if(i == cSeqPoints || ipOffset < pOffsets[i+1])
{
// ...[생략]...
}
}
// ...[생략해서는 안되는 코드, 그런데 저는 생략했음!]...
delete[] pOffsets; // 배열 할당 해제
// ...[생략]...
delete[] pDocs; // 배열 할당 해제
(위의 코드를 알고 그대로 사용했다면 실수를 안했을 텐데!) 제 나름대로 ISymUnmanagedMethod 인터페이스 사용방법을 터득해 나가다가 저렇게 "...[생략해서는 안되는 코드]..." 영역을 생략해 버리고 작성하게 되는 실수를 했습니다.
그야말로 무심코! 배열 할당을 했으니 그냥 할당된 배열만 짝을 맞춰 해제시키기만 했고 하루 정도의 응용 프로그램 부하 테스트에서 여지없이 Memory Leak이 발생한 것입니다.
사실, 나름대로 완벽하게 new/delete를 맞췄기 때문에 처음에는 '참 희한하다...' 라고 생각했는데. ^^
알고 보니, 배열이 포함한 요소의 타입이 인터페이스인 경우 그것까지도 명백하게 해제를 해야 Memory Leak이 안 났습니다. 즉, "...[생략해서는 안되는 코드]..."가 이렇게 존재해야만 합니다.
if(pDocs)
{
for(ULONG32 i = 0; i < cSeqPoints; i++)
{
if(pDocs[i])
{
pDocs[i]->Release();
}
}
}
외부에서 얻어온 인터페이스는 철저하게 해제를 해줘야 한다는 상식!... 을 어느새 잊어버린 것입니다. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]