Microsoft MVP성태의 닷넷 이야기
.NET Framework: 607. C# try/catch/finally의 IL 코드 표현 [링크 복사], [링크+제목 복사],
조회: 13224
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 2개 있습니다.)
.NET Framework: 607. C# try/catch/finally의 IL 코드 표현
; https://www.sysnet.pe.kr/2/0/11053

닷넷: 2262. C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조
; https://www.sysnet.pe.kr/2/0/13625




C# try/catch/finally의 IL 코드 표현

다음과 같은 C# 소스 코드를 컴파일러로 빌드하고 나면,

private void PageInit()
{
    try
    {
        Console.WriteLine("Try");
    }
    catch (Exception ex)
    {
        WriteLog(ex);
    }
    finally
    {
        Console.WriteLine("Finally");
    }
}

PageInit 메서드에 대해 대략 다음과 같은 식의 IL 바이트 배열이 나옵니다.

1b 30 02 00 2d 00 00 00 03 00 00 11 72 35 00 00 70 28 29 00 00 0a de 20 25 28 2a 00 00 0a 0a 02 06 28 16 00 00 06 28 2b 00 00 0a de 0b 72 5d 00 00 70 28 29 00 00 0a dc 2a 00 00 00 01 1c 00 00 00 00 00 00 0c 0c 00 15 27 00 00 01 02 00 00 00 21 21 00 0b 00 00 00 00 1b


위의 바이트에는 CLR Method의 헤더와 코드, try/catch/fianlly의 예외 섹터가 포함되는데, 분석은 표준에 맞춰서 하면 됩니다. 처음 1byte인 0x1b를 통해서 FAT Header를 갖는 메서드임을 알 수 있고 이에 대한 구조체는 다음과 같이 정해져 있습니다.

// CorHdr.h 

typedef struct IMAGE_COR_ILMETHOD_FAT
{
    unsigned Flags    : 12;     // Flags see code:CorILMethodFlags
    unsigned Size     :  4;     // size in DWords of this structure (currently 3)
    unsigned MaxStack : 16;     // maximum number of items (I4, I, I8, obj ...), on the operand stack
    DWORD   CodeSize;           // size of the code
    mdSignature   LocalVarSigTok;     // token that indicates the signature of the local vars (0 means none)

} IMAGE_COR_ILMETHOD_FAT;

즉, 처음 12바이트는 Header의 크기가 됩니다.

1b
30 02 00
2d 00 00 00 (Code Size: 45)
03 00 00 11 (LocalVarSig)

코드 크기는 헤더 안에 담겨 있는데 "2d 00 00 00"이 됩니다. Little endian이기 때문에 0x0000002d == 45가 됩니다. 따라서 헤더 이후의 45바이트는 여러분이 작성한 코드의 IL 표현이 됩니다.

72 35 00 00 70 28 29 00
00 0a de 20 25 28 2a 00
00 0a 0a 02 06 28 16 00
00 06 28 2b 00 00 0a de
0b 72 5d 00 00 70 28 29
00 00 0a dc 2a

표준에는 IL 코드의 정렬이 4바이트라고 정해져 있습니다. 위의 바이트 크기는 45바이트인데, 48 바이트 정렬이 되어야 하므로 패딩을 위해 3바이트가 추가됩니다.

00 00 00

이후의 바이트 정보는 try/catch/finally의 예외가 됩니다. 예외 정보도 나름의 Header 영역을 가지고 있는데 처음의 1바이트가 Header의 Fat/Thin 유형을 나타냅니다. 이 글에서 다루는 메서드는 "01"로 나오는데 이는 Small 유형이고 따라서 Header의 크기도 4바이트로 결정됩니다.

01 1c 00 00 

그리고 Header의 2번째 바이트 값인 0x1c == 28은 헤더를 포함한 총 예외 정보의 바이트 수입니다. 따라서, 28 - 4 == 24바이트가 이후에 나와야 하고 이는 (12바이트 크기인) Small 유형의 예외 정보 목록을 가집니다.

// CorHdr.h

typedef struct IMAGE_COR_ILMETHOD_SECT_EH_CLAUSE_SMALL
{
#ifdef _WIN64
    unsigned            Flags         : 16;
#else // !_WIN64
    CorExceptionFlag    Flags         : 16;
#endif
    unsigned            TryOffset     : 16;
    unsigned            TryLength     : 8;  // relative to start of try block
    unsigned            HandlerOffset : 16;
    unsigned            HandlerLength : 8;  // relative to start of handler
    union {
        DWORD       ClassToken;
        DWORD       FilterOffset;
    };
} IMAGE_COR_ILMETHOD_SECT_EH_CLAUSE_SMALL;

이에 따라 나머지 정보는 다음과 같은 식으로 분석될 수 있습니다.

00 00 (Flags)
00 00 (TryOffset)
0c (TryLength)
0c 00 (HandlerOffset)
15 (HandlerLength)
27 00 00 01 (ClassTokenOrFilterOffset)

02 00 (Flags)
00 00 (TryOffset)
21 (TryLength)
21 00 (HandlerOffset)
0b (HandlerLength)
00 00 00 00 (ClassTokenOrFilterOffset)

어렵지 않죠?! ^^




그런데, 최근에 재미있는 사례를 하나 접하게 되었습니다.

해당 고객사는 VB.NET을 사용하였고 코드가 .aspx 파일 내에 포함되어 있는 유형이었는데,

<%@ Page Language="VB" AutoEventWireup="false" %>

<script runat="server">
    Private Sub PageInit()
        Try
            Console.WriteLine("Try")
        Catch ex As Exception
            WriteLog(ex)
        Finally
            Console.WriteLine("Finally")
        End Try
    End Sub

    Private Sub WriteLog(ByVal ex As Exception)
    End Sub
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
</head>
<body>
</body>
</html>

이렇게 정의된 PageInit 메서드의 IL 코드가 저희 제품에서 해석이 안 되는 것이었습니다. 도대체 어떤 일이 있는 것일까요? ^^

다행히 해당 메서드의 IL 코드 원본을 얻었는데 다음과 같았습니다.

1b 30 02 00 36 00 00 00 08 00 00 11 00 00 72 01 00 00 70 28 19 00 00 0a 00 de 24 25 28 1a 00 00 0a 0a 00 02 06 6f 19 00 00 06 00 28 1b 00 00 0a de 0d 00 72 29 00 00 70 28 19 00 00 0a 00 dc 00 00 2a 00 00 01 18 00 00 00 00 02 00 0d 0f 00 17 20 00 00 01 02 00 02 00 24 26 00 0d 00 00


이 중에서 헤더를 분석해 보면 다음과 같은 정보를 얻을 수 있습니다.

Total IL Bytes: 94
Header Kind: 27
Fat Header
max stack: 2
CodeSize: 54(+ padding size : 2 = 56)
Has Sector
Clause Kind: 1
ThinFormat
Sector #0
CorExceptionFlags == 0
Try 2, Len 13 (AbsOffest: 15), Catch 15, Len 23 (AbsOffest: 38)
classTokenOrFilterOffset: 32

그런데, 이상합니다. 총 94 바이트 중에 Fat 메서드의 Header 영역으로 12바이트가 소비되고 패딩을 포함한 코드의 크기가 56바이트입니다. 그럼 94 - 12 - 56 = 26 바이트가 남는데, 다시 예외 정보의 Header인 4바이트를 제외하면 22바이트가 남습니다.

문제는? 예외를 나타내는 IMAGE_COR_ILMETHOD_SECT_EH_CLAUSE_SMALL 구조체 1개의 크기가 12바이트라는 점입니다. 즉, 예외 정보의 남은 바이트가 12의 배수로 나와야 하는데 22바이트가 나왔으니 나머지 2바이트가 잘린 것입니다.

원인은 결국 예전에 소개했던 것과 같은 이유로 밝혀집니다.

닷넷 프로파일러 - ICorProfilerInfo::GetILFunctionBody 함수 버그
; https://www.sysnet.pe.kr/2/0/1377

음... 어쩔 수 없습니다. CLR 2.0에서는 예외 정보의 크기가 12 배수가 아니어도 0 ~ 3바이트 이내의 차이를 갖는다면 정상적인 예외 정보의 수로 포함시켜 처리를 해야 합니다. (참고로, 이 문제는 동일한 응용 프로그램을 CLR 4 환경에서 실행하면 문제없이 잘 실행됩니다.)




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







[최초 등록일: ]
[최종 수정일: 10/6/2016]

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

비밀번호

댓글 작성자
 




... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...
NoWriterDateCnt.TitleFile(s)
12953정성태2/2/20226730Linux: 48. Windows 11 + WSL 우분투 GUI 환경에서 한글 출력
12952정성태2/2/20227269.NET Framework: 1148. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 오디오 필터 예제(filter_audio.c)파일 다운로드1
12951정성태2/2/20227229.NET Framework: 1147. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 오디오 필터링 예제(filtering_audio.c)파일 다운로드1
12950정성태2/1/20226783.NET Framework: 1146. .NET 6에 추가되지 않은 Generic Math (예: INumber<T>)
12949정성태2/1/20226634.NET Framework: 1145. C# - ffmpeg(FFmpeg.AutoGen) - Codec 정보 열람 및 사용 준비파일 다운로드1
12948정성태1/30/20226768.NET Framework: 1144. C# - ffmpeg(FFmpeg.AutoGen) AVFormatContext를 이용해 ffprobe처럼 정보 출력파일 다운로드1
12947정성태1/30/20227959개발 환경 구성: 634. ffmpeg.exe - 기존 동영상 컨테이너에 다중 스트림을 추가하는 방법
12946정성태1/28/20226423오류 유형: 792. .NET Core - 로컬 개발 중에 docker 호스팅으로 바꾸는 경우 SQL 서버 접근 방법
12945정성태1/28/20226734오류 유형: 791. SQL 서버 로그인 시 localhost는 되고, 127.0.0.1로는 안 되는 문제
12944정성태1/28/20229203.NET Framework: 1143. C# - Entity Framework Core 6 개요
12943정성태1/27/20228032.NET Framework: 1142. .NET 5+로 포팅 시 플랫폼 호환성 경고 메시지(SYSLIB0006, SYSLIB0011, CA1416)파일 다운로드1
12942정성태1/27/20228283.NET Framework: 1141. XmlSerializer와 Dictionary 타입파일 다운로드1
12941정성태1/26/20229703오류 유형: 790. AKS/k8s - pod 상태가 Pending으로 지속되는 경우
12940정성태1/26/20226995오류 유형: 789. AKS에서 hpa에 따른 autoscale 기능이 동작하지 않는다면?
12939정성태1/25/20227778.NET Framework: 1140. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 MP3 오디오 파일 인코딩/디코딩하는 예제파일 다운로드1
12938정성태1/24/202210125개발 환경 구성: 633. Docker Desktop + k8s 환경에서 local 이미지를 사용하는 방법
12937정성태1/24/20227950.NET Framework: 1139. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 오디오(mp2) 인코딩하는 예제(encode_audio.c) [2]파일 다운로드1
12936정성태1/22/20227904.NET Framework: 1138. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 멀티미디어 파일의 메타데이터를 보여주는 예제(metadata.c)파일 다운로드1
12935정성태1/22/20228144.NET Framework: 1137. ffmpeg의 파일 해시 예제(ffhash.c)를 C#으로 포팅파일 다운로드1
12934정성태1/22/20227701오류 유형: 788. Warning C6262 Function uses '65564' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. [2]
12933정성태1/21/20228219.NET Framework: 1136. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 MP2 오디오 파일 디코딩 예제(decode_audio.c)파일 다운로드1
12932정성태1/20/20228665.NET Framework: 1135. C# - ffmpeg(FFmpeg.AutoGen)로 하드웨어 가속기를 이용한 비디오 디코딩 예제(hw_decode.c) [2]파일 다운로드1
12931정성태1/20/20226658개발 환경 구성: 632. ASP.NET Core 프로젝트를 AKS/k8s에 올리는 과정
12930정성태1/19/20227413개발 환경 구성: 631. AKS/k8s의 Volume에 파일 복사하는 방법
12929정성태1/19/20227219개발 환경 구성: 630. AKS/k8s의 Pod에 Volume 연결하는 방법
12928정성태1/18/20227315개발 환경 구성: 629. AKS/Kubernetes에서 호스팅 중인 pod에 shell(/bin/bash)로 진입하는 방법
... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...