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 환경에서 실행하면 문제없이 잘 실행됩니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]