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

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)
12180정성태3/10/2020399오류 유형: 600. "Docker Desktop for Windows" - EXPOSE 포트가 LISTENING 되지 않는 문제
12179정성태3/10/2020574개발 환경 구성: 481. docker - PostgreSQL 컨테이너 실행
12178정성태3/10/2020457개발 환경 구성: 480. Linux 운영체제의 docker를 위한 tcp 바인딩 추가
12177정성태3/9/2020534개발 환경 구성: 479. docker - MySQL 컨테이너 실행
12176정성태3/9/2020391개발 환경 구성: 478. 파일의 (sha256 등의) 해시 값(checksum) 확인하는 방법
12175정성태3/8/2020592개발 환경 구성: 477. "Docker Desktop for Windows"의 "Linux Container" 모드를 위한 tcp 바인딩 추가
12174정성태3/8/2020737개발 환경 구성: 476. DockerDesktopVM의 파일 시스템 접근 [2]
12173정성태3/8/2020683개발 환경 구성: 475. docker - SQL Server 2019 컨테이너 실행 [1]
12172정성태3/8/20201035개발 환경 구성: 474. docker - container에서 root 권한 명령어 실행(sudo)
12171정성태3/6/2020672VS.NET IDE: 143. Visual Studio - ASP.NET Core Web Application의 "Enable Docker Support" 옵션으로 달라지는 점
12170정성태3/6/2020564오류 유형: 599. "Docker Desktop is switching..." 메시지와 DockerDesktopVM CPU 소비 현상
12169정성태3/5/2020953개발 환경 구성: 473. Windows nanoserver에 대한 docker pull의 태그 사용
12168정성태3/8/2020845개발 환경 구성: 472. 윈도우 환경에서의 dockerd.exe("Docker Engine" 서비스)가 Linux의 것과 다른 점
12167정성태3/5/2020664개발 환경 구성: 471. C# - 닷넷 응용 프로그램에서 DB2 Express-C 데이터베이스 사용 (3) - ibmcom/db2express-c 컨테이너 사용
12166정성태3/14/2020538개발 환경 구성: 470. Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치
12165정성태8/18/2020551.NET Framework: 900. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 네 번째 이야기(Monitor.Enter 후킹)파일 다운로드1
12164정성태2/29/2020641오류 유형: 598. Surface Pro 6 - Windows Hello Face Software Device가 인식이 안 되는 문제
12163정성태2/27/2020590.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/28/2020746디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생파일 다운로드2
12161정성태2/26/2020391오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/2020460개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/2020355오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/26/2020533디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/27/2020537디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/2020405오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/2020445오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...