Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

배열을 반환하는 C# COM 개체의 메서드를 C++에서 사용 시 메모리 누수 현상

아래와 같은 질문이 있군요. ^^

C# dll 파일을 C++에서 사용 시 memory leak 문제
; https://www.sysnet.pe.kr/3/0/5453

질문하신 분이 예제 정리를 잘해주셨지만, ^^ 그래도 조금 더 욕심을 내 재현 프로젝트를 간략화시켜 보겠습니다. 우선 C# 프로젝트는 다음의 코드만 작성할 수 있습니다.

using System;
using System.Runtime.InteropServices;

namespace ClassLibrary1
{
    [ComVisible(true)]
    [Guid("8EA9EAA8-CA3D-4584-B1E0-7B9561757CA4")]
    public interface ICSharpLibrary
    {
        int[] GetData();
        string GetName();
    }

    [ComVisible(true)]
    [Guid("B62A2B51-621D-41AA-8F4F-021E404B593C")]
    public class CSharpLibrary : ICSharpLibrary
    {
        public int[] GetData()
        {
            return new int[1024];
        }

        public string GetName()
        {
            return new string('x', 1024);
        }
    }
}

그런 다음 프로젝트 속성의 "Build" / "Output" 범주에 있는 "Register for COM interop" 옵션을 체크해 둡니다. (이 옵션을 체크하면 비주얼 스튜디오를 "관리자 권한"으로 실행해야 대상 프로젝트를 정상적으로 빌드할 수 있습니다.)

그리고 C++ 프로젝트와의 빌드 연동을 위해 DLL/PDB/TLB 파일을 다음의 빌드 이벤트 스크립트로 솔루션 디렉터리 하위의 Lib에 모아두도록 합니다.

robocopy $(TargetDir) $(SolutionDir)Lib $(TargetName).dll $(TargetName).pdb $(TargetName).tlb
exit 0

그럼, C++ 예제 코드는 이렇게 간단하게 구성할 수 있습니다.

#include <iostream>
#include <Windows.h>

#import "./../Lib/ClassLibrary1.tlb" no_namespace named_guids

int main()
{
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if (!SUCCEEDED(hr))
    {
        return false;
    }

    ICSharpLibrary* lib = nullptr;

    do
    {
        hr = CoCreateInstance(CLSID_CSharpLibrary, NULL, CLSCTX_INPROC_SERVER, IID_ICSharpLibrary, reinterpret_cast<void**>(&lib));

        if (!SUCCEEDED(hr))
        {
            break;
        }

        while (true)
        {
            SAFEARRAY* array = lib->GetData();
            _bstr_t bstrName = lib->GetName();
        }

    } while (false);

    if (lib != nullptr)
    {
        lib->Release();
        lib = nullptr;
    }

    CoUninitialize();
}

tlb 파일에 대한 #import 구문으로 생성한 C++ TLH, TLI 파일을 보면 위와 같이 C# 라이브러리를 사용한 이유를 알 수 있습니다.

// classlibrary1.tlh

#pragma once
#pragma pack(push, 8)

#include <comdef.h>

struct __declspec(uuid("af9d8dd7-d8ae-427b-b1e7-77b7feeb343c")) /* LIBID */ __ClassLibrary1;
struct __declspec(uuid("8ea9eaa8-ca3d-4584-b1e0-7b9561757ca4")) /* dual interface */ ICSharpLibrary;
struct /* coclass */ CSharpLibrary;
struct __declspec(uuid("d6c19716-755b-3d95-8cbc-40d68a3dbfea")) /* dual interface */ _CSharpLibrary;

_COM_SMARTPTR_TYPEDEF(ICSharpLibrary, __uuidof(ICSharpLibrary));
_COM_SMARTPTR_TYPEDEF(_CSharpLibrary, __uuidof(_CSharpLibrary));

struct __declspec(uuid("8ea9eaa8-ca3d-4584-b1e0-7b9561757ca4"))
ICSharpLibrary : IDispatch
{
    SAFEARRAY * GetData ( );
    _bstr_t GetName ( );

      virtual HRESULT __stdcall raw_GetData (
        /*[out,retval]*/ SAFEARRAY * * pRetVal ) = 0;
      virtual HRESULT __stdcall raw_GetName (
        /*[out,retval]*/ BSTR * pRetVal ) = 0;
};

struct __declspec(uuid("b62a2b51-621d-41aa-8f4f-021e404b593c"))
CSharpLibrary;

struct __declspec(uuid("d6c19716-755b-3d95-8cbc-40d68a3dbfea"))
_CSharpLibrary : IDispatch {};

extern "C" const GUID __declspec(selectany) LIBID_ClassLibrary1 = {0xaf9d8dd7,0xd8ae,0x427b,{0xb1,0xe7,0x77,0xb7,0xfe,0xeb,0x34,0x3c}};
extern "C" const GUID __declspec(selectany) IID_ICSharpLibrary = {0x8ea9eaa8,0xca3d,0x4584,{0xb1,0xe0,0x7b,0x95,0x61,0x75,0x7c,0xa4}};
extern "C" const GUID __declspec(selectany) CLSID_CSharpLibrary = {0xb62a2b51,0x621d,0x41aa,{0x8f,0x4f,0x02,0x1e,0x40,0x4b,0x59,0x3c}};
extern "C" const GUID __declspec(selectany) IID__CSharpLibrary = {0xd6c19716,0x755b,0x3d95,{0x8c,0xbc,0x40,0xd6,0x8a,0x3d,0xbf,0xea}};

// ...[생략]...

#pragma pack(pop)

// classlibrary1.tli

inline SAFEARRAY * ICSharpLibrary::GetData ( ) {
    SAFEARRAY * _result = 0;
    HRESULT _hr = raw_GetData(&_result);
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _result;
}

inline _bstr_t ICSharpLibrary::GetName ( ) {
    BSTR _result = 0;
    HRESULT _hr = raw_GetName(&_result);
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _bstr_t(_result, false);
}

마지막으로, 빌드 완료 후 실행하면 메모리 누수가 발생하고!




반면, GetData 호출을 제거하면,

while (true)
{
    // SAFEARRAY* array = lib->GetData();
    _bstr_t bstrName = lib->GetName();
}

이번엔 메모리 누수가 없습니다. 그럼 대충 짐작이 가시겠죠? ^^ 실제로 classlibrary1.tli 파일을 보면, GetName의 경우 raw_GetName 메서드를 통해 BSTR을 받아옵니다.

inline _bstr_t ICSharpLibrary::GetName ( ) {
    BSTR _result = 0;
    HRESULT _hr = raw_GetName(&_result);
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _bstr_t(_result, false);
}

사실, C# 측에서는 COM 개체로 호출하는 측에 반환할 문자열을 GC Heap에 있는 것을 그냥 전달할 수 없습니다. 따라서 COM 개체 간의 interop으로 약속된 BSTR 메모리를 할당해서 그것을 반환하게 되는데, 이에 대해 호출 측에서는 BSTR 메모리를 사용 후 반드시 해제해야 합니다. GetName 함수에서는 _bstr_t로 C# 측에서 반환한 BSTR을 래핑하는데,

_bstr_t Class
; https://docs.microsoft.com/en-us/cpp/cpp/bstr-t-class

내부적으로 _bstr_t 측에서 참조 카운트를 이용해 자원 해제까지 담당하므로 SysFreeString으로 BSTR 텍스트 자원이 해제가 됩니다. 실제로 GetName에서 어떻게 참조 카운트가 변하는지 다음과 같이 유추할 수 있습니다.

inline _bstr_t ICSharpLibrary::GetName ( ) {
    BSTR _result = 0;
    HRESULT _hr = raw_GetName(&_result); // C# 측에서 BSTR 자원을 SysAllocString으로 할당 후 반환
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _bstr_t(_result, false); // _bstr_t 인스턴스가 반환되지만 2번째 인자의 false로 인해 원본 BSTR을 가리키면서 참조 카운트 = 1 상태 유지
}

그리고 저 메서드를 사용하는 측에서 보면,

while (true)
{
    _bstr_t bstrName = lib->GetName(); // 반환 순간 _bstr_t가 담고 있는 참조 카운트는 1

    // block scope을 벗어나는 순간 _bstr_t의 파괴자에 의해 참조 카운트는 -1
    // 따라서 참조 카운트가 0이므로 BSTR 문자열 메모리에 대해 SysFreeString을 호출해 자원 해제
}

결국 깨끗하게 자원 정리가 되는 것을 볼 수 있습니다.




그런데, GetData의 동작 방식은 다릅니다.

inline SAFEARRAY * ICSharpLibrary::GetData ( ) {
    SAFEARRAY * _result = 0;
    HRESULT _hr = raw_GetData(&_result);
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _result;
}

raw_GetData의 호출로 C# 측에서는 int 배열을 담고 있는 SAFEARRAY를 SafeArrayCreate 함수를 이용해 할당 후 반환합니다. 그런데, GetName과는 다르게 SAFEARRAY에 대한 참조 카운트를 관리하는 별도의 래퍼 타입을 반환하지 않고, 직접 SAFEARRAY 인스턴스를 반환하고 있습니다.

따라서, 호출 측에서는 반드시 SafeArrayDestroy를 호출해야만,

while (true)
{
    SAFEARRAY* data = lib->GetData();
    // ...[data 사용]...
    SafeArrayDestroy(data);
}

정상적인 자원 정리가 됩니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




참고로, 본문에서 "Register for COM interop" 옵션을 체크해 두어야 한다고 했지만 개인적으로는 "관리자 권한"으로 비주얼 스튜디오를 실행하는 것을 선호하지 않기 때문에 다음과 같은 식으로,

C# DLL로부터 TLB 및 C/C++ 헤더 파일(TLH)을 생성하는 방법
; https://www.sysnet.pe.kr/2/0/12220

C# DLL에 정의한 (메서드 내부의 코드가 아닌) 메서드 signature의 변경이나 추가/삭제 시에만 관리자 권한의 cmd.exe 창을 띄워 regasm.exe로 등록하는 방식으로 개발합니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 1/18/2021 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 



2021-01-18 09시38분
[안녕하세요] 글 잘 읽었습니다.

C# dll wrapping을 처음 하다보니 디버깅을 제대로 못 한 것 같네요.. 잘 배워갑니다 :)

제 경우에는 SAFEARRAY에서 SafeArrayAccessData 함수로 데이터를 받아 써서 이후에 SafeArrayUnaccessData 함수를 써야 제대로 메모리가 해제되더라고요 ㅎㅎ

커피 맛있게 드세요 ^^
[손님]

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12547정성태3/3/2021164오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/2021191개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/28/2021697.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [7]
12544정성태3/28/2021375.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태3/12/2021303VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태3/3/2021328개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법
12541정성태2/18/2021414개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태3/28/2021428.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태3/28/2021429Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태3/28/2021569.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태3/28/2021620.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기
12536정성태2/9/2021461개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/10/2021295개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/17/2021461개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작파일 다운로드1
12533정성태2/8/2021393개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/2021319개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF)
12531정성태2/5/2021326개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/5/2021403개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/2021332개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO
12528정성태2/9/2021338개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/2021416개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/2021320개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/2021257개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태2/18/2021319개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/2021343개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/2021329개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...