이 글의 문맥을 분석하여 이글루스에 있는 많은 글 중에서 관련성이 높은 글을 자동으로 검색해 낸 결과입니다.
|
Gflags.exe는 Windows System Diagnostics 를 위해 debugging tools for windows에서 제공하는 Tool이다.
상위의 그림만 봐서는 이해하기 어려울 수도 있지만, Application에 대한 System registry의 일부 설정을 통하여 메모리누수나 handle 누수를 tracking 하거나 pageheap을 enable 하여 Heap corruption을 Troubleshooting 할 수 있다. 메모리누수에 대한 Gflags 설정.
1) Gflags에 보면, image file tab에서 “Create user mode stack trace database” 라는 option을 enable 한다. (그전에 image text box에 해당 image 이름을 입력해야 한다) Command 창에서는 “gflags –i CrashApp.exe +ust” 하고 실행하면 된다. 2) 설정이 되었는지는 레지스트리를 통해서 확인할 수 있는 데, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\CrashApp.exe 로 이동하여, key중에 REG_DWORD 로 GlobalFlag 가 존재하는 지 확인하고, 해당 값이 0x1000으로 설정되어 있으면 정상적으로 설정이 된 것이다. 3) 그리고, UDDH를 위해서 Symbol 설정을 해야 한다. Command창에서 “SET _NT_SYMBOL_PATH=C:\LeakAppSymbols;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols” 하여 환경변수로 설정하고, 4) Application을 수행한 후, Leak 현상이 발생하기 전 해당 Command 창에 “umdh –p:PID > C:\start.txt” 를 수행한다. 5) 충분히 Leak 현상이 발생하고 나면, “umdh –p:PID > end.txt” 를 command창에서 한번 더 수행을 하고, 6) 마지막으로 해당 command 창에서 “umdh –d start.txt end.txt > result.txt” 를 수행하여 결과를 얻는 다. 결과 report 는 Leak이전에 잡은 Log와 이후에 잡은 Log를 통해서 차이가 발생하는 Allocation에 대한 결과를 다음과 같이 보여준다. Symbol이 맞아야 Callstack에서 Allocation이 발생하는 Code의 위치를 정확히 확인할 수 있다. /////////////// + 20480 ( 20480 - 0) 1 allocs BackTrace1516DC + 1 ( 1 - 0) BackTrace1516DC allocations ntdll!RtlTimeToElapsedTimeFields+00001963 buggy!memoryLeak+00000036 (d:\myprog\dbgt\exe\buggy\buggy.cpp, 20) buggy!wmain+000000C1 (d:\myprog\dbgt\exe\buggy\buggy.cpp, 225) buggy!wmainCRTStartup+0000016A kernel32!BaseThreadInitThunk+00000012 ntdll!RtlInitializeExceptionChain+00000063 ntdll!RtlInitializeExceptionChain+00000036 Total increase == 20480 requested + 24 overhead = 20504 ///////////// 여기서 increase 된 20480은 bytes 단위이다. Heap은 Code에서 사용하는 Memory Block으로 Application에서 메모리 할당이나 해제 시 잘못된 사용으로 인하여 Corruption이 발생할 수 있다. 일반적인 Heap corruption이 발생하는 경우는 다음과 같다. ² Buffer overrun ² Buffer underrun ² Double Free ² Free block에 대한 access ² 메모리 재사용에 대한 문제, (예를 들어, 메모리를 free하고 동일한 size를 재사용할 때, 동일한 address가 잡힐 것이라는 기대감에서 발생할 수 있는 문제. 등등 Heap Corruption 은 임의의 Heap block이 깨진 이후 다른 시점에 Allocation이나 Memory 사용시 예기치 않게 Access Violation이 발생할 수 있기 때문에 AV 순간 Crash dump를 수집한다고 해도 해당 Callstack이 문제 근원이 되는 Callstack이 아닐 가능성이 매우 크다. 이를 위해서 Gflags 는 allocation을 Check하도록 설정하여 잘못된 사용시 이를 Debugger를 통해 알려줄 수 있도록 도와준다. - Normal Pageheap ² free될 때만 allocation check ² gflags –p /enable CrashApp.exe ² High Memory usage의 process를 위해서는 “gflags.exe –p /enable lsass.exe /decommit /random 20” 를 이용할 수 있다. random 20은 20% 만 pageheap이 enable 된다는 의미. - Full Pageheap ² No access pages를 사용하여 Allocation block에 padding ² gflags –p /enable CrashApp.exe /full ² 만일, /decommit option을 이용하면, Memory를 1/2 로 줄일 수 있다. n gflags –p /enable CrashApp.exe /full /decommit n decommit 은 No access pages 대신에 reserved virtual memory zone을 이용함. Heap이 깨졌다는 것은 어떻게 알까? 먼저, AV crash dump를 확인하고, Heap corruption 여부를 확인하여 다시 Crash dump를 수집하게 된다. 간혹, 다음과 같은 Function stack에서 AV가 발생하는 것을 볼 수 있다.
Pageheap에 따른 Heap block의 구조는 아래의 문서를 참조한다. 중요한 것은 Block header나 suffix bytes 인데, 이는 Heap block이 Allocated된 것인지 Free된 것인지를 확인할 수 있는 정보가 된다. //// http://msdn.microsoft.com/en-us/library/cc266933.aspx발췌... The following diagrams show the arrangement of heap blocks. These are valid in Windows 2000 (Service Pack 1 and later), Windows XP, and later versions of Windows. Light page heap block — allocated: +-----+---------------+---+ Light page heap block — freed: +-----+---------------+---+ Full page heap block — allocated: +-----+---------+---+------- Full page heap block — freed: +-----+---------+---+-------
|
 by 강세윤 카테고리
이글루링크
최근 등록된 덧글
그러세요
by 강세윤 at 12/15 오늘 많이 헤매다..알게 .. by youna at 12/14 글 잘 읽었습니다 . 전 .. by 위시 at 11/26 어렷다 by klhk at 11/09 dhjjgbem by kl at 11/09 17번부터 어떻게 접는지.. by tykim0131 at 10/28 ATL이나 MFC를 이용하.. by 김명신 at 09/24 복원되었군요.. 제 RSS.. by 강세윤 at 09/24 허걱, 하고 있는 것으로.. by 강세윤 at 09/15 RSS 주소 서비스는 안 .. by 정성태 at 09/15 이글루 파인더
 | |||
