Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제

물론, 일부러 그럴 필요는 없지만 ^^ 그래도 이것이 얼마나 간단할 수 있는지 살펴보겠습니다. 지난 글에 설명했듯이,

C#에서 확인해 보는 관리 힙의 인스턴스 구조
; https://www.sysnet.pe.kr/2/0/1176

관리 힙에 있는 객체는 메모리 구조가 OBJECT Header와 Method Table 주소 및 각 타입의 필드로 이뤄집니다.

int[] test = new int[1];
test[0] = 0xff;

Console.WriteLine("int [] ================== ");
fixed (int* p1 = &test[0])
{
    Console.WriteLine("OBJECT Header(SyncBlock Index): " + (*(p1 - 3)).ToString("x"));
    Console.WriteLine("MethodTable Address: " + (*(p1 - 2)).ToString("x"));
    Console.WriteLine("배열 요소 크기: " + (*(p1 - 1)).ToString("x"));
    Console.WriteLine("0번째 배열 값: " + (*(p1 - 0)).ToString("x"));
}

그래서, 만약 관리 힙의 시작 주소를 알 수 있다면 그 이후로 Method Table 주소를 이용해 해당 타입의 필드 정보를 보고 객체가 소유한 메모리의 크기를 구해 다음 객체가 할당된 시작점으로 이동할 수 있습니다. 실제로 GC는 이런 식으로 GC Heap을 열람하면서 객체 정리를 해나갑니다.

그렇다면, 당연히 "Method Table 주소"를 구할 수 없다면 GC는 해당 객체의 크기를 알 수 없어 패닉(?)에 빠지게 될 것입니다. ^^; 이것을 다음과 같이 간단한 코드로 테스트할 수 있습니다.

using System;

class Program
{
    static unsafe void Main(string[] args)
    {
        int[] test = new int[1];
        test[0] = 0xff;

        Console.WriteLine("int [] ================== ");
        fixed (int* p1 = &test[0])
        {
            Console.WriteLine("OBJECT Header(SyncBlock Index): " + (*(p1 - 3)).ToString("x"));
            Console.WriteLine("MethodTable Address: " + (*(p1 - 2)).ToString("x"));

            *(p1 - 2) = 0; // GC의 MethodTable 주소 정보를 제거

            Console.WriteLine("배열 요소 크기: " + (*(p1 - 1)).ToString("x"));
            Console.WriteLine("0번째 배열 값: " + (*(p1 - 0)).ToString("x"));
        }

        GC.Collect(); // 여기서 비정상 종료

        Console.WriteLine("GCed!"); // 이 코드는 절대 수행되지 않음
    }
}

이때 발생하는 이벤트 로그를 보면 다음과 같습니다.

Log Name:      Application
Source:        .NET Runtime
Date:          2019-11-15 오후 10:45:32
Event ID:      1023
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
Application: ConsoleApp1.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 709E21D1 (70900000) with exit code 80131506.

Log Name:      Application
Source:        Application Error
Date:          2019-11-15 오후 10:45:32
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
Faulting application name: ConsoleApp1.exe, version: 1.0.0.0, time stamp: 0xf39545aa
Faulting module name: clr.dll, version: 4.8.4042.0, time stamp: 0x5d7a9e00
Exception code: 0xc0000005
Fault offset: 0x000e21d1
Faulting process id: 0x5f1c
Faulting application start time: 0x01d59b565e367a5c
Faulting application path: c:\temp\ConsoleApp1\bin\Debug\ConsoleApp1.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: b790601d-4a9d-470c-b8a9-144beabee7ab
Faulting package full name: 
Faulting package-relative application ID: 

Log Name:      Application
Source:        Windows Error Reporting
Date:          2019-11-15 오후 10:45:35
Event ID:      1001
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
Fault bucket 2275602419194088766, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: ConsoleApp1.exe
P2: 1.0.0.0
P3: f39545aa
P4: clr.dll
P5: 4.8.4042.0
P6: 5d7a9e00
P7: c0000005
P8: 000e21d1
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER4A26.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER4A95.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER4AC5.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER4AC7.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER4AE7.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_ConsoleApp1.exe_205af63bf864821f555164beb5b9ebbca41c_870f1ae3_efc6993a-ca59-44d7-95e8-0749fcc35e9a

Analysis symbol: 
Rechecking for solution: 0
Report Id: b790601d-4a9d-470c-b8a9-144beabee7ab
Report Status: 268435456
Hashed bucket: f856d214730f94afbf949057f6154d3e
Cab Guid: 0

비록 이번에도 "Heap"이 깨지긴 했지만 말 그대로 .NET CLR의 관리 Heap이기 때문에 Native Heap이 깨졌을 때처럼 FaultTolerantHeap과 같은 대우는 받지 못합니다.

어쨌든 이런 식으로 관리 힙이 깨져 비정상 종료하는 경우 메모리 덤프를 받으면, 다음과 같은 콜 스택을 확인할 수 있습니다.

clr!WKS::gc_heap::mark_object_simple+60 
clr!WKS::GCHeap::Promote+a8 
clr!GcEnumObject+37 
clr!EECodeManager::EnumGcRefs+840 
clr!GcStackCrawlCallBack+139 
clr!Thread::StackWalkFramesEx+92 
clr!Thread::StackWalkFrames+9d 
clr!standalone::ScanStackRoots+43 
clr!GCToEEInterface::GcScanRoots+db 
clr!WKS::gc_heap::mark_phase+170 
clr!WKS::gc_heap::gc1+ae 
clr!WKS::gc_heap::garbage_collect+367 
clr!WKS::GCHeap::GarbageCollectGeneration+1bd 
clr!WKS::GCHeap::GarbageCollectTry+71 
clr!WKS::GCHeap::GarbageCollect+ac 
clr!GCInterface::Collect+69 
mscorlib_ni!System.GC.Collect()+31 
mscorlib_ni!System.GC.Collect()+31 
Program.Main(System.String[])+188 
clr!CallDescrWorkerInternal+34 
clr!CallDescrWorkerWithHandler+6b 
clr!MethodDescCallSite::CallTargetWorker+16a 
clr!RunMain+1b3 
clr!Assembly::ExecuteMainMethod+f7 
clr!SystemDomain::ExecuteMainMethod+5ef 
clr!ExecuteEXE+4c 
clr!_CorExeMainInternal+dc 
clr!_CorExeMain+4d 
mscoreei!_CorExeMain+d6 
mscoree!ShellShim__CorExeMain+9e 
mscoree!_CorExeMain_Exported+8 
kernel32!BaseThreadInitThunk+19 
ntdll!__RtlUserThreadStart+2f 
ntdll!_RtlUserThreadStart+1b 

참고로 이때의 예외 유형은 System.ExecutionEngineException입니다.

아무튼, 테스트를 통해 알 수 있겠지만 관리 힙의 데이터 주소를 native 측에 전달하거나, 또는 unsafe/fixed로 다룰 때는 그만큼 주의를 기울여야 합니다. 위의 사례와는 반대로 해당 데이터를 넘어서 쓰게 되면 다음 객체의 헤더를 덮어쓰게 될 것이고 그럴 때에도 GC는 헤어날 수 없는 충격에 빠지게 될 테니까요. ^^




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 11/16/2019 ]

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

비밀번호

댓글 쓴 사람
 




1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12106정성태1/8/202090VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작
12105정성태1/8/202093디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/9/2020197DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [2]
12103정성태1/12/2020144DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/2020166디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/8/2020125.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/202081.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/2020126디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회
12098정성태1/2/2020137.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법
12097정성태1/2/202080디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태1/2/2020192디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작
12095정성태12/27/2019166VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/2019209.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/2019359.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/2019168디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/2019240디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일
12090정성태12/24/2019231.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점
12089정성태12/23/2019151디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/2019125Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
12087정성태12/21/2019182디버깅 기술: 145. windbg/sos - Dictionary의 entries 배열 내용을 모두 덤프하는 방법 (do_hashtable.py)
12086정성태12/20/2019231디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/2019165오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/21/2019221디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py)
12083정성태12/17/2019325Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [1]
12082정성태12/17/2019150오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/2019205개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...