Microsoft MVP성태의 닷넷 이야기
.NET Framework: 742. windbg로 확인하는 Finalizer를 가진 객체의 GC 과정 [링크 복사], [링크+제목 복사],
조회: 14909
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
[gc_dtor.zip]    
(연관된 글이 2개 있습니다.)

windbg로 확인하는 Finalizer를 가진 객체의 GC 과정

객체가 GC되었는지 확인하는 방법을 알아봤는데요.

windbg로 확인하는 객체의 GC 여부
; https://www.sysnet.pe.kr/2/0/11509

그럼, Finalizer를 가진 객체로도 테스트를 해보겠습니다. 이를 위해 지난 예제의 Program 클래스에 Finalizer를 추가한 후,

using System;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            Instance();

            Console.ReadLine();    // .NET 4 + x64 + Release 모드로 실행 후,
                                   // 이 시점에 Dump를 뜨고,

            GC.Collect(2, GCCollectionMode.Forced);     // 엔터를 치면 GC가 수행되고,
                                                        // 이 시점에 다시 Dump를 뜸
            Console.ReadLine();
        }

        private static void Instance()
        {
            Program pg = new Program();
        }

        ~Program()
        {
            Console.WriteLine("GCed");
        }
    }
}

GC.Collect 수행 전/후에 따라 덤프를 뜹니다. 우선 GC.Collect를 수행하기 전의 덤프를 분석하면 지난 글에서 설명한 데로 Program 객체는 0 세대 힙에 놓인 것을 확인할 수 있습니다.

0:000> .loadby sos clr

0:000> !dumpheap -type ConsoleApp2.Program
         Address               MT     Size
0000018414812df0 00007ff8a7185a28       24     

Statistics:
              MT    Count    TotalSize Class Name
00007ff8a7185a28        1           24 ConsoleApp2.Program
Total 1 objects

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000018414811030
generation 1 starts at 0x0000018414811018
generation 2 starts at 0x0000018414811000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000018414810000  0000018414811000  0000018414817fe8  0x6fe8(28648)
Large object heap starts at 0x0000018424811000
         segment             begin         allocated              size
0000018424810000  0000018424811000  00000184248199e8  0x89e8(35304)
Total Size:              Size: 0xf9d0 (63952) bytes.
------------------------------
GC Heap Size:            Size: 0xf9d0 (63952) bytes.

이 상태에서 finalizequeue 명령을 실행하면 다음과 같은 결과를 얻을 수 있습니다.

0:000> !finalizequeue
SyncBlocks to be cleaned up: 0
Free-Threaded Interfaces to be released: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
generation 0 has 9 finalizable objects (0000018412b5a610->0000018412b5a658)
generation 1 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
generation 2 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
Ready for finalization 0 objects (0000018412b5a658->0000018412b5a658)
Statistics for all finalizable objects (including all objects ready for finalization):
              MT    Count    TotalSize Class Name
00007ff902a13f60        1           24 System.WeakReference
00007ff8a7185a28        1           24 ConsoleApp2.Program
00007ff902a31a38        1           32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
00007ff902a319a8        1           32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle
00007ff9029fc3e0        1           32 Microsoft.Win32.SafeHandles.SafePEFileHandle
00007ff9029fd680        1           64 System.Threading.ReaderWriterLock
00007ff9029fa3f0        2           64 Microsoft.Win32.SafeHandles.SafeFileHandle
00007ff9029f7f28        1           96 System.Threading.Thread
Total 9 objects

이 출력 결과에서 아래의 세 라인이 바로 소멸자 큐(Finalization queue)의 내용이고,

generation 0 has 9 finalizable objects (0000018412b5a610->0000018412b5a658)
generation 1 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)
generation 2 has 0 finalizable objects (0000018412b5a610->0000018412b5a610)

그다음 라인의 내용이 FReachable Queue입니다.

Ready for finalization 0 objects (0000018412b5a658->0000018412b5a658)

즉, 현재 소멸자를 가진 클래스의 인스턴스가 9개 생성된 상태이고 해당 객체들은 모두 0 세대 힙에 있습니다.

참고로, dumpheap으로 구한 객체의 주소로 gcroot 명령어를 이용하면 Finalization queue에도 root 참조가 있는지 곧바로 확인할 수 있습니다.

0:000> !gcroot 0000018414812df0
Finalizer Queue:
    0000018414812df0
    -> 0000018414812df0 ConsoleApp2.Program




그다음 GC.Collect를 수행한 후의 덤프를 분석하면, 이번에는 Program 객체가 GC되지 않고 1 세대 힙에 놓인 것을 볼 수 있습니다.

0:000> !dumpheap -type ConsoleApp2.Program
         Address               MT     Size
0000018414812df0 00007ff8a7185a28       24     

Statistics:
              MT    Count    TotalSize Class Name
00007ff8a7185a28        1           24 ConsoleApp2.Program
Total 1 objects

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000018414816c88
generation 1 starts at 0x0000018414811018
generation 2 starts at 0x0000018414811000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000018414810000  0000018414811000  0000018414818ca0  0x7ca0(31904)
Large object heap starts at 0x0000018424811000
         segment             begin         allocated              size
0000018424810000  0000018424811000  00000184248199e8  0x89e8(35304)
Total Size:              Size: 0x10688 (67208) bytes.
------------------------------
GC Heap Size:            Size: 0x10688 (67208) bytes.

즉, Finalizer를 구현한 객체는 소멸자 큐에 등록된 것으로 인해 여전히 root 참조가 살아 있으므로 GC.Collect 이후 곧바로 GC되지 않고 1 세대 힙으로 승격하게 됩니다. (물론 일반적인 객체였다면 이 과정에서 root 참조가 없기 때문에 정리가 됩니다.)

또한 1 세대 힙으로 승격함과 동시에 소멸자 큐의 root 참조가 없어지고 FReachable Queue로 이동하게 됩니다. 그래서 첫 번째 GC.Collect 이후에는 다음과 같이 소멸자 큐의 등록이 없어진 것을 확인할 수 있습니다.

0:000> !gcroot 0000018414812df0
Found 0 unique roots (run '!GCRoot -all' to see all roots).




소멸자의 동작과 관련해 "소멸자 큐(finalization queue)"와 "FReachable Queue"가 있습니다. 제 책에서도 설명했지만, GC.Collect 시에 소멸자 큐에서 나온 객체는 FReachable Queue로 이동하고 이 시점에 대기하고 있던 소멸자 스레드가 FReachable Queue에 있는 항목을 곧바로 꺼내 소멸자 메서드를 호출합니다.

그래서 FReachable Queue에 객체가 있는 경우를 확인하기가 (일반적인 응용 프로그램의 경우) 쉽지 않습니다.

물론 억지로 ^^ 재현하면 쉽게 확인할 수 있습니다. 가령, 다음과 같이 소멸자를 갖는 객체를 하나 더 추가하는 것입니다.

using System;
using System.Threading;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            Instance();
            Console.ReadLine();

            GC.Collect(2, GCCollectionMode.Forced);
            Console.ReadLine();
        }

        private static void Instance()
        {
            Program pg = new Program();
            LongDtor ld = new LongDtor();
        }

        ~Program()
        {
            Thread.Sleep(1000 * 60);
            Console.WriteLine("Program.GCed");
        }
    }

    class LongDtor
    {
        ~LongDtor()
        {
            Thread.Sleep(1000 * 60);
            Console.WriteLine("LongDtor.GCed");
        }
    }
}

위와 같이 하면, GC.Collect 이후 2개의 객체(pg, ld)가 소멸자 큐에서 FReachable 큐로 이동할 것입니다. 이동하자마자 소멸자 스레드에 의해 꺼내져 dtor를 실행하게 될 텐데, 어느 쪽의 객체를 먼저 꺼내든 60초의 시간 동안 그다음 객체를 꺼낼 수 없으므로 적어도 1개의 객체가 FReachable 큐에 (60초 동안은) 머물게 됩니다.

따라서 첫 번째 GC.Collect 호출 후 덤프를 떠서 finalizequeue 명령으로 확인하면,

0:000> !finalizequeue
SyncBlocks to be cleaned up: 0
Free-Threaded Interfaces to be released: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
generation 0 has 0 finalizable objects (000001f15f1bc4d0->000001f15f1bc4d0)
generation 1 has 8 finalizable objects (000001f15f1bc490->000001f15f1bc4d0)
generation 2 has 0 finalizable objects (000001f15f1bc490->000001f15f1bc490)
Ready for finalization 1 objects (000001f15f1bc4d0->000001f15f1bc4d8)
Statistics for all finalizable objects (including all objects ready for finalization):
              MT    Count    TotalSize Class Name
00007ff902a13f60        1           24 System.WeakReference
00007ff8a7175a30        1           24 ConsoleApp2.Program
00007ff902a31a38        1           32 Microsoft.Win32.SafeHandles.SafeFileMappingHandle
00007ff902a319a8        1           32 Microsoft.Win32.SafeHandles.SafeViewOfFileHandle
00007ff9029fc3e0        1           32 Microsoft.Win32.SafeHandles.SafePEFileHandle
00007ff9029fd680        1           64 System.Threading.ReaderWriterLock
00007ff9029fa3f0        2           64 Microsoft.Win32.SafeHandles.SafeFileHandle
00007ff9029f7f28        1           96 System.Threading.Thread
Total 9 objects

GC.Collect로 인해 0 세대 힙에 있던 소멸자를 가진 10개의 객체 중 8개가 소멸자 큐(Finalization queue)에 머물러 있고,

generation 0 has 0 finalizable objects (000001f15f1bc4d0->000001f15f1bc4d0)
generation 1 has 8 finalizable objects (000001f15f1bc490->000001f15f1bc4d0)
generation 2 has 0 finalizable objects (000001f15f1bc490->000001f15f1bc490)

2개의 객체는 Finalization queue에서 꺼내져 Freachable Queue에 들어갔습니다.

Ready for finalization 1 objects (000001f15f1bc4d0->000001f15f1bc4d8) 

만약 소멸자 스레드에 의해 꺼내지지 않았다면 위의 출력 결과는 "2 objects"로 나오겠지만, 거의 곧바로 실행되기 때문에 Freachable Queue에 들어간 2개의 객체 중 한 개는 꺼내져서 소멸자 스레드에 의해 dtor가 호출 중이며 나머지 한 개는 아직 Freachable Queue에 머물러 있는 것입니다.

실제로 Freachable Queue에서 남아 있는 1개의 객체를 다음과 같이 덤프할 수 있습니다.

0:000> dq 000001f15f1bc4d0 L1
000001f1`5f1bc4d0  00000184`14812df0

0:000> !do 00000184`14812df0
Name:        ConsoleApp2.Program
MethodTable: 00007ff8a7185a28
EEClass:     00007ff8a71824f8
Size:        24(0x18) bytes
File:        E:\ConsoleApp2\bin\Release\ConsoleApp2.exe
Fields:
None

따라서 현재 소멸자 스레드에 의해 꺼내져 실행되고 있는 객체는 ConsoleApp2.LongDtor 클래스의 인스턴스임을 예상할 수 있습니다.




이번 테스트를 통해 제가 그동안 잘못 알고 있던 것을 바로잡을 수 있게 되었습니다. 예전에는 다음과 같은 절차로 소멸자를 가진 객체가 없어진다고 알고 있었는데,

1. dtor를 가진 객체 생성
    1.1 GC Heap 0 세대에 객체가 등록됨
[객체가 scope을 벗어남]
2. 첫 번째 GC 수행 시 root 참조들이 없지만 dtor를 가지므로 GC heap에서 Finalization queue로 이동
3. 두 번째 GC 수행 시 Finalization queue에서 Freachable Queue로 이동하고, 그 순간 소멸자 스레드에 의해 실행

실제로 테스트해본 결과 다음과 같이 진행되고 있었습니다.

1. dtor를 가진 객체 생성
    1.1 GC Heap 0 세대에 객체가 등록됨
    1.2 소멸자 큐(Finalization queue)에도 객체가 등록됨
[객체가 scope을 벗어남]
2. 첫 번째 GC 수행 시
    2.1 소멸자 큐에 root 참조가 있으므로 1 세대로 승격
    2.2 소멸자 큐의 root 참조를 비우고 Freachable Queue로 이동
    2.3 Freachable Queue로 이동하자마자 소멸자 스레드가 꺼내 실행
[따라서 이 시점에는 GC Heap 1 세대에만 참조가 있음]
3. 두 번째 GC 수행 시 GC Heap 1 세대의 객체가 정리됨

음... 책 내용을 수정해야겠군요. ^^




그렇다면 WeakReference는 Finalizer를 가진 객체에 대해 언제 IsAlive 값이 False가 될까요? 얼핏 생각해 보면, 첫 번째 GC 수행 후에도 여전히 GC Heap 1 세대에 살아있으므로 그 시점까지는 IsAlive 값이 True로 유지될 듯싶었는데요. 테스트 결과 GC Heap 1 세대에 있음에도 불구하고 무조건 IsAlive = False로 되는 것을 확인할 수 있습니다.

이러한 시점 상의 문제로 WeakReference는 해당 객체가 실제로 GC되지 않아도 참조를 잃어버리게 됩니다. 예를 들어 (권장되지 않지만) 소멸자에서 해당 객체를 다시 부활(resurrection) 시키는 경우도 있을 텐데, WeakReference는 이런 상황을 고려하지 않습니다.

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 4/30/2018]

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)
12130정성태1/26/20209748VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202015311.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
12128정성태1/26/202010107오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/25/20209980.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/202010797.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/20208684VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/23/202010515VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/202011982웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법 [2]
12122정성태1/20/20208982.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/20/20209556VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/19/202010969.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/202010998디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/202011639개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기 [1]
12117정성태1/15/202010633디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/202011102디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/202010881디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/202012745디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거 [1]파일 다운로드3
12113정성태1/12/202013363오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib' [1]
12112정성태1/12/20209972오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태1/12/202013191디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [16]파일 다운로드1
12110정성태1/11/202011797디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례 [5]파일 다운로드1
12109정성태1/10/20209727오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/20209731오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/202010690.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202012121VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작 [1]
12105정성태1/8/202010747디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
... 46  47  48  49  50  51  52  53  54  55  56  57  58  59  [60]  ...