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)
12068정성태11/28/20191099디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [2]파일 다운로드2
12067정성태11/27/2019736디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/2019527디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/2019637디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/2019890오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/2019674디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태12/20/2019546디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/2019613Windows: 165. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/21/2019673디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/2019642디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/2019630디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/2019454오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/2019799개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/2019407개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/2019843.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/2019505Windows: 164. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/2019439오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태12/2/2019939개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/2019648Windows: 163. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/2019500.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/2019676Windows: 163. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/20191081Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태11/9/2019607오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/2019509오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
12044정성태10/27/2019612오류 유형: 575. mstest.exe - System.Resources.MissingSatelliteAssemblyException: The satellite assembly named "Microsoft.VisualStudio.ProductKeyDialog.resources.dll, ..."
12043정성태10/27/2019614오류 유형: 574. Windows 10 설치 시 오류 - 0xC1900101 - 0x4001E
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...