Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 11개 있습니다.)
디버깅 기술: 6. .NET 예외 처리 정리
; https://www.sysnet.pe.kr/2/0/316

디버깅 기술: 15. First-Chance Exception
; https://www.sysnet.pe.kr/2/0/510

디버깅 기술: 16. Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석
; https://www.sysnet.pe.kr/2/0/595

.NET Framework: 110. WPF - 전역 예외 처리
; https://www.sysnet.pe.kr/2/0/614

디버깅 기술: 31. Windbg - Visual Studio 디버그 상태에서 종료해 버리는 응용 프로그램
; https://www.sysnet.pe.kr/2/0/957

디버깅 기술: 42. Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석 - (2)
; https://www.sysnet.pe.kr/2/0/1096

.NET Framework: 534. ASP.NET 응용 프로그램이 예외로 프로세스가 종료된다면?
; https://www.sysnet.pe.kr/2/0/10863

디버깅 기술: 110. 비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상
; https://www.sysnet.pe.kr/2/0/11383

디버깅 기술: 119. windbg 분석 사례 - 종료자(Finalizer)에서 예외가 발생한 경우 비정상 종료(Crash) 발생
; https://www.sysnet.pe.kr/2/0/11732

닷넷: 2148. C# - async 유무에 따른 awaitable 메서드의 병렬 및 예외 처리
; https://www.sysnet.pe.kr/2/0/13422

닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
; https://www.sysnet.pe.kr/2/0/13551




Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석 - (2)


예전에 Watson Bucket에 대해 정리해 드렸는데요.

Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석
; https://www.sysnet.pe.kr/2/0/595

이번에는, 최근에 만난 CLR Watson Bucket 정보를 예로 들어 한 단계 더 살펴보겠습니다.

P1: ...[생략]...
P2: 1.0.0.0
P3: 4c7c6f0c
P4(AsmAndModName): system.data
P5: 2.0.0.0
P6: 4889deaf
P7(MethodDef): 971
P8(Offset):  8
P9: system.outofmemoryexception
P10: NIL

위의 P4(AsmAndModName) 정보에 따라 System.Data.dll 파일을 ildasm.exe에서 열고 "Control + M" 키를 누른 후, P7(MethodDef)에 지정된 0x971번 메서드 정보를 얻어냅니다.

watson_bucket_trace_1.png

"
Method #81 (06000971)
MethodName : get_Namespace (06000971)
Flags : [Public] [HideBySig] [ReuseSlot] [SpecialName]
RVA : 0x001e0edc
ImplFlags : [IL] [Managed]
CallCnvntn : [DEFAULT]
hasThis
ReturnType : String
No arguments.
"


문제는, 이렇게 찾아낸 정보만으로는 위의 메서드가 속한 클래스를 알 수 없다는 것입니다.

이를 알아내기 위해 ".NET Reflector"의 검색을 이용해서 "get_Namespace" 메서드를 가지는 타입을 찾아 보았는데, 그 결과 "System.Data"에는 다음과 같이 3개가 검색되었습니다.

watson_bucket_trace_2.png

위의 3개 중에서 어떤 것이 06000971 메서드에 해당하는 것일까요? 이를 알기 위해 다시 ildasm.exe 결과에서 각각 찾아봐야 했는데 결국 System.Data.DataTable에 있는 get_Namespace 메서드가 아래와 같이 동일한 06000971임을 발견하게 되었습니다. (다행히, 이번에는 3개에 불과했지만 혹시 100개가 넘는 동일한 이름의 메서드가 있다면 어떨까요? 개선된 방법에 대해서는 따로 글을 올리겠습니다.)

watson_bucket_trace_3.png

재차 ".NET Reflector"로 와서 System.Data.DataTable.Namespace 속성의 get 메서드를 살펴보면 다음과 같은 소스 코드를 구할 수 있습니다.

public string get_Namespace()
{
    if (this.tableNamespace == null)
    {
        return this.GetInheritedNamespace(new List<DataTable>());
    }
    return this.tableNamespace;
}

(사실, 이 정도 나왔으면 더 볼 것도 없이 P9에서 알려주는 "system.outofmemoryexception" 예외가 발생한 곳은 "new List<DataTable>());"임을 짐작할 수 있지만!)

예외가 발생한 구체적인 코드를 알아내려면 P8(Offset) 값인 8에 위치하는 IL 코드를 찾아내야 합니다. 이를 위해 ".NET Reflector"의 보기를 "IL"로 변경해서 확인하면 다음과 같고,

.method public hidebysig specialname instance string get_Namespace() cil managed
{
    .maxstack 2
    L_0000: ldarg.0 
    L_0001: ldfld string System.Data.DataTable::tableNamespace
    L_0006: brtrue.s L_0014
    L_0008: ldarg.0 
    L_0009: newobj instance void [mscorlib]System.Collections.Generic.List`1<class System.Data.DataTable>::.ctor()
    L_000e: call instance string System.Data.DataTable::GetInheritedNamespace(class [mscorlib]System.Collections.Generic.List`1<class System.Data.DataTable>)
    L_0013: ret 
    L_0014: ldarg.0 
    L_0015: ldfld string System.Data.DataTable::tableNamespace
    L_001a: ret 
}

L_0008 위치에는 ldarg.0이 있는데, 여기서는 메모리 할당이 있을만한 여지가 없지요. 하지만 그 다음에 보니 'newobj'가 있는데,,, 바로 그 코드 때문에 P9에서 알려주는 "system.outofmemoryexception" 예외가 발생한 것임을 추측할 수 있습니다.

그런데, 왜? L_0009를 가리키지 않고 L_0008일까요? 예전의 글에 설명한 Bucket 정보 해석에서는 정확하게 IL Code Offset 위치를 짚어낸 것과 비교하면 이번에는 왠지 너무 끼워 맞추기 설명이 아닐까 하는 의심이 듭니다. ^^

개인적으로도 이 부분이 마음에 걸려서, 좀 더 확인해 보기 위해 OOM 예외가 발생하는 간단한 예제를 만들어 테스트해 보았는데, 역시나 Watson Bucket의 위치는 위의 글에서 본 것처럼 한 단계 이전의 위치를 가리키고 있었습니다. (그 이상의 구체적인 이유는 더 이상 파악할 수 없습니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 6/23/2021]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  [57]  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12546정성태3/3/202118469개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202121212.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202121578.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/202119241VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202120893개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/202118404개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/202119842.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/202119662Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202120211.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202120271.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202119355개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/202118451개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/202119184개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/202117654개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/202119451개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/202117964개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202121395개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202119886개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/202119703개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/202119693개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/202116423개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/202115279개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/202115813개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/202117693개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202119905개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/202118198개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
... 46  47  48  49  50  51  52  53  54  55  56  [57]  58  59  60  ...