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

비밀번호

댓글 작성자
 




... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
12069정성태12/2/201921160디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201929618디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201921167디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201920724디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201918605디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201922024오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201920942디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201920040디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201920251Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201922597디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201921810디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201922433디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/201917660오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201923942개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/201917913개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201919561.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201920681Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201919539오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201923776개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201921176Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201921737.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201921573Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201924010Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태10/29/201918130오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/201918549오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
12044정성태10/27/201917687오류 유형: 575. mstest.exe - System.Resources.MissingSatelliteAssemblyException: The satellite assembly named "Microsoft.VisualStudio.ProductKeyDialog.resources.dll, ..."
... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...