Microsoft MVP성태의 닷넷 이야기
.NET Framework: 601. ElementHost 컨트롤의 메모리 누수 현상 [링크 복사], [링크+제목 복사],
조회: 15259
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

ElementHost 컨트롤의 메모리 누수 현상

아래와 같은 질문이 있습니다.

ElementHost Memory Leak 현상
; https://www.sysnet.pe.kr/3/0/4749

ElementHost Memory Leak 현상 (아래내용과 동일 첨부 추가^^)
; https://www.sysnet.pe.kr/3/0/4750


"ElementHost Memory Leak 현상 (아래내용과 동일 첨부 추가^^)" 글의 첨부 파일은 WPF 프로젝트와 WinForm 프로젝트를 포함하고 있는데, 소스 코드를 약간 바꿔 1초마다 다음과 같이 ElementHost를 지속적으로 사용/제거를 반복하게 만들어 보았습니다.

public partial class MainForm : Form
{
    Timer t = new Timer();

    public MainForm()
    {
        InitializeComponent();
        t.Interval = 1000;
        t.Tick += T_Tick;
        t.Start();
    }

    private void T_Tick(object sender, EventArgs e)
    {
        for (int i = 0; i < 10; i++)
        {
            ElementHost addElementHost = new ElementHost() { Dock = DockStyle.Top };
            addElementHost.Child = new WPFUserControl();

            this.testPanel.Controls.Add(addElementHost);
        }

        this.testPanel.Controls.Clear();

        Process proc = Process.GetCurrentProcess();
        string mem = proc.PrivateMemorySize64.ToString();

        if (this.memoryLabel.InvokeRequired)
        {
            this.Invoke(new MethodInvoker(delegate { this.memoryLabel.Text = mem; }));
        }
        else
        {
            this.memoryLabel.Text = mem;
        }
    }
}

그래서 이 예제 프로젝트를 실행하면 1초마다 10개의 ElementHost가 생성/삭제를 반복하는데 메모리는 지속적으로 증가하는 것을 볼 수 있습니다. 한마디로 메모리 누수(memory leak) 현상이 발생하고 있는 것입니다.

이런 경우 가장 먼저 해볼 것이 ElementHost가 IDisposable을 구현하고 있는가... 하는 것입니다. 실제로 ElementHost는 Control을 상속받고 있으며 여기서 IDisposable을 상속받고 있습니다. 즉, 가능하면 Dispose를 호출해 주는 것이 권장되는 것입니다.

이럴 때 다음과 같이 예제 코드를 바꿔보면 메모리 누수 현상이 없어집니다.

List<ElementHost> list = new List<ElementHost>();

for (int i = 0; i < 10; i++)
{
    ElementHost addElementHost = new ElementHost() { Dock = DockStyle.Top };
    addElementHost.Child = new WPFUserControl();

    list.Add(addElementHost);
    this.testPanel.Controls.Add(addElementHost);
}

this.testPanel.Controls.Clear();

foreach (ElementHost elem in list)
{
    elem.Dispose();
}


그런데, 왜 이런 현상이 발생하는 것일까요? 원래 (Full) GC가 2번 이상 수행되면 Finalizer가 구현된 경우 Dispose가 불리게끔 되어 있습니다. 실제로 Control 객체가 상속받은 System.ComponentModel.Component의 Finalize 메서드는 내부적으로 다음과 같이 Dispose(false) 코드를 호출합니다.

~Component()
{
    this.Dispose(false);
}

Dispose 메서드에 false를 주었다는 것은 "Managed 자원"은 어차피 Finalizer가 호출되는 시점이면 GC에 의해 해제되었을 것이므로 "Unmanaged 자원을 해제"하라는 것입니다. 이에 대해서는 다음의 글을 참고하세요.

.NET IDisposable 처리 정리
; https://www.sysnet.pe.kr/2/0/347

그런데, ElementHost에 정의된 Dispose 메서드에는 false인 경우 해제하는 작업이 전혀 없습니다.

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        try
        {
            if (this._hostContainerInternal != null)
            {
                this._hostContainerInternal.Dispose();
                this._hostContainerInternal = null;
            }
        }
        finally
        {
            try
            {
                if (this._hwndSource != null)
                {
                    this.DisposeHWndSource();
                }
            }
            finally
            {
                InputManager.Current.PostProcessInput -= new ProcessInputEventHandler(this.InputManager_PostProcessInput);
                IDisposable child = this.Child as IDisposable;
                if (child != null)
                {
                    child.Dispose();
                }
            }
        }
    }
    base.Dispose(disposing);
}

그렇다면, ElementHost의 Dispose 작업 중에 처리되는 것들은 Unmanaged 자원과는 전혀 무관하다는 것인데요. 아무래도 이것은 개발자의 오판이 아닌가 싶습니다. 왜냐하면, 분명히 있기 때문에 저렇게 메모리 누수가 발생하는 것이므로!

게다가 재현 코드를 돌려 보면, dwm.exe 프로세스의 메모리도 함께 증가하면서 전체적인 UI 반응이 느려지는 것을 볼 수 있습니다. 즉, ElementHost로 인해 해제되지 않은 자원 중에 dwm.exe와도 관련있는 자원이 해제되지 않아서 발생하는 문제로 보입니다.

어쨌든, 그나마 다행인 것은 Dispose를 명시적으로 호출해 주면 메모리 누수가 없어지므로 사용하는 측에서 좀 조심해 주면 됩니다. ^^




호기심 삼아서, ElementHost.Dispose의 어떤 과정에서 leak을 유발했는지 좀 더 탐색해 보았습니다. 그 결과, 다음과 같이 2가지 코드만 수행해 주면 문제가 없었습니다.

Type type = elem.GetType();

// this.DisposeHWndSource();
MethodInfo miHwnd = type.GetMethod("DisposeHWndSource", BindingFlags.NonPublic | BindingFlags.Instance);
if (miHwnd == null)
{
    return;
}

miHwnd.Invoke(elem, null);

// InputManager.Current.PostProcessInput -= new ProcessInputEventHandler(this.InputManager_PostProcessInput);
MethodInfo mi = type.GetMethod("InputManager_PostProcessInput", BindingFlags.NonPublic | BindingFlags.Instance);
if (mi == null)
{
    return;
}

Type inputManager = InputManager.Current.GetType();
EventInfo ei = inputManager.GetEvent("PostProcessInput");

System.Delegate del = mi.CreateDelegate(typeof(System.Windows.Input.ProcessInputEventHandler), elem);

MethodInfo ei_mi = ei.GetRemoveMethod();
ei_mi.Invoke(InputManager.Current, new object[] { del });

즉, 다음의 2개 코드였습니다.

this.DisposeHWndSource();
InputManager.Current.PostProcessInput -= new ProcessInputEventHandler(this.InputManager_PostProcessInput);

InputManager.Current.PostProcessInput의 경우 전역 static 이벤트 핸들러를 제거하지 않아서 문제가 발생하는 것은 일면 이해가 됩니다. 전역 객체로부터의 이벤트를 제거하지 않아 지속적으로 객체가 해제되지 않는 현상은 이미 유명합니다.

아울러 DisposeHWndSource 코드에도 메모리 누수 코드가 있습니다.

private void DisposeHWndSource()
{
    ((IKeyboardInputSink) this._hwndSource).KeyboardInputSite = null;
    this._hwndSource.Dispose();
    this._hwndSource = null;
}

실제로 이 중에서 this._hwndSource.Dispose()만 Reflection을 이용해 호출해도 메모리 누수 현상이 사라집니다.

FieldInfo fieldInfo = type.GetField("_hwndSource", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);

if (fieldInfo == null)
{
    return;
}

object objValue = fieldInfo.GetValue(elem);
Type hwndSourceType = objValue.GetType();
MethodInfo miDispose = hwndSourceType.GetMethod("Dispose", BindingFlags.Public | BindingFlags.Instance);
miDispose.Invoke(objValue, null);

HwndSource 타입은 IDisposable은 구현했지만 Finalizer는 구현하지 않은 객체입니다. 따라서, 해당 클래스에서 Unmanaged 자원을 사용하고 있는 코드가 있다면 (Dispose를 명시적으로 호출하지 않는 경우) GC에 의해 절대로 해제되지 않게 됩니다. 그리고, 테스트 결과는 그것이 있다는 것을 의미합니다. HwndSource.Dispose 메서드를 분석해서 구체적으로 어떤 것이 문제인지 확인해 보고 싶었으나... 코드가 너무 길어서 ^^ 이건 나중으로 미루겠습니다.




이 글의 결론은, ElementHost를 사용하지 않더라도 다음의 2가지 사항을 주의해야 한다는 것입니다.

  1. InputManager.Current로부터 이벤트 구독을 했다면 반드시 해제해 줄 것.
  2. HwndSource 객체를 생성했다면 반드시 명시적으로 Dispose 메서드를 호출해 줄 것.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...
NoWriterDateCnt.TitleFile(s)
12151정성태2/22/202011629.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011494.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011239.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012470디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202011077디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202011347.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202010576.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/13/202010546.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/20208670.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/12/202010402.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/20209993.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [2]파일 다운로드1
12140정성태2/10/20209818.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/202011201.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/202013938.NET Framework: 885. C# - 닷넷 응용 프로그램에서 SQLite 사용 [6]파일 다운로드1
12137정성태2/9/20209164오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/20209544Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태2/6/202013173개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [2]
12134정성태2/5/202013360.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [5]파일 다운로드1
12133정성태2/5/202010588디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태1/28/202012158.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/202012229개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법 [1]
12130정성태1/26/20209699VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202015289.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
12128정성태1/26/202010080오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/25/20209949.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/202010732.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...