http://littles.egloos.com/3383811
Windows 메모리/리소스 누수 디버깅 기법들
모든 소프트웨어 개발 프로젝트에서 제품을 출시하기 위한 메모리 누수(leak)와의 싸움은 피할 수 없는 어려운 과제이다.
여러 프로젝트에서의 개인적인 경험을 통해, Windows 환경에서 유용한 여러가지 메모리 누수 디버깅 방법 들을 정리해 보았다.
Win32 API에 탑재되어 있는 _CrtDumpMemoryLeaks()에 의한 메모리 누수 덤프 기능은 비록 정확히 어느 소스코드에 의해 leak 발생하는지까지 알려주지는 않으나 최소한 leak이 존재하는지 여부는 보고해준다. 따라서 어플리케이션의 검증용으로 매우 유용하다.
이 기능을 응용하여 메모리 누수 위치까지 알기 위해서는 Microsoft의 Application Verifier를 통해 callstack trace를 활성화 시켜주면 된다. 다만, 작은 크기의 할당이 매우 많이 일어나는 경우를 추적하기 위해서는 프로세스의 메모리가 부족할 수 있다는 제약이 있다.
위의 전 과정에 대한 더욱 상세한 안내를 위해서는, http://jpassing.com/2008/09/01/effective-leak-detection-with-the-debug-crt-and-application-verifier/ 링크가 많은 도움이 될 것이다.
이 기법은 메모리 누수의 원인을 찾기 위해서라기 보다는, 개발중인 어플리케이션의 메모리 누수 검증용으로 코드의 exit 처리 부분에 삽입해 두면 유용하다.
2. UMDH
Microsoft Windows SDK에 포함되어 있는 UMDH를 사용하면 원하는 시점에 메모리 할당 내역의 스냅샷을 덤프할 수 있으며, 두 스냅샷의 비교를 통해 구체적으로 메모리가 소스코드의 어느부분에서 할당되고 해제되었는지 그 상세한 내역을 확인할 수 있어, 메모리 누수의 확인에 매우 유용한 툴이다. 게다가 실행 성능 저하와 추가 메모리 부담이 매우 적으므로 반드시 숙지해야 할 툴이라 할 수 있다. (자세한 사용법은 http://support.microsoft.com/kb/268343/ko 참고)
2. UMDH
Microsoft Windows SDK에 포함되어 있는 UMDH를 사용하면 원하는 시점에 메모리 할당 내역의 스냅샷을 덤프할 수 있으며, 두 스냅샷의 비교를 통해 구체적으로 메모리가 소스코드의 어느부분에서 할당되고 해제되었는지 그 상세한 내역을 확인할 수 있어, 메모리 누수의 확인에 매우 유용한 툴이다. 게다가 실행 성능 저하와 추가 메모리 부담이 매우 적으므로 반드시 숙지해야 할 툴이라 할 수 있다. (자세한 사용법은 http://support.microsoft.com/kb/268343/ko 참고)
이 툴을 이용한 메모리 누수 위치 확인 방법은 일반적으로 다음과 같다.
- 개발중인 어플리케이션에 대해 UMDH의 추적기능을 활성화
- 첫번쨰 메모리 스냅샷 덤프
- 확인을 원하는 실행 지점에서 두번쨰 메모리 스냅샷 덤프
- 위의 두 메모리 스냅샷 간의 메모리 할당 증감 내역 비교
- (UMDH 추적기능 비활성화)
3. 자체 메모리 관리자
메모리 사용의 내역을 추적하는 가장 확실한 방법은 자체 메모리 관리자와 할당 내역 프로파일러를 구현하는 것이다.
자체 메모리 관리자는 일반적으로 다음과 같은 방식으로 구현될 수 있다.
- new operator와 malloc 등을 override 하여 새로운 할당자(allocator)를 구현하고, 모든 소스코드가 이를 명시적으로 사용하도록 함. 그러나 할당자를 사용하는 코드가 실수로 다른 할당자를 사용하거나, 유사한 인자(arguments)를 받는 다른 할당자들이 혼재되어 include되는 경우 이에 의한 버그를 추적하기 매우 어려워지는 단점이있다. 반면, 소스코드 수준에서 다양한 할당자를 선택적으로 사용하거나 추가적인 힌트를 전달할 수 있다는 점에서 장기적으로는 추천할 만 하다.
- HeapAlloc 등의 OS 함수를 후킹하여, 이에 들어오는 호출들이 자체 구현을 거쳐가도록 함. Windows DLL을 후킹하기 위한 절차가 다소 까다로우나, 한 번 구현하고 나면 소스코드의 실수로 다른 할당자와 혼재되는 것이 근본적으로 방지된다는 점에서 매우 강력하다.
4. 자체 프로파일러
자체 메모리 관리자가 존재한다면, 여기에 어떤 방법으로든 프로파일러를 구현할 수 있다.
다음과 같은 방식의 프로파일러들이 고려 가능할 것이다.
5. 상용 툴들
MemoryValidator, Rational Purify 등의 상용 툴들을 사용하여 어플리케이션을 실행하면 다양한 정보를 자동으로 얻을 수 있다. 다만, 어플리케이션의 실행 성능이 현저하게 느려지므로 문제점 재현에 어려움이 따르는 경우가 많다.
6. 그 외 진단에 유용한 무료 툴들
- 모든 메모리 할당과 해제를 로그로 남겨서 외부 분석기를 이용해 사후 분석
- 소스 코드에 카테고리 정보를 추가하여, 각 카테고리 별로 메모리 사용량 계측. 실시간 통계도 가능
5. 상용 툴들
MemoryValidator, Rational Purify 등의 상용 툴들을 사용하여 어플리케이션을 실행하면 다양한 정보를 자동으로 얻을 수 있다. 다만, 어플리케이션의 실행 성능이 현저하게 느려지므로 문제점 재현에 어려움이 따르는 경우가 많다.
6. 그 외 진단에 유용한 무료 툴들
- Process Explorer
- VMMap
어플리케이션이 사용하는 메모리는 OS의 관점에서 다양한 종류와 상태로 분류된다.
현재 프로세스가 사용하는 메모리의 상태의 큰 그림을 알아야 어플리케이션의 총체적인 메모리 이슈를 파악하는데에 유용하다. VMMap 툴은 프로세스의 메모리 사용 현황을 직관적인 다이어그램으로 보여준다.
'프로그래밍 > 기타정보' 카테고리의 다른 글
게임 엔진 프레임워크 (0) | 2015.01.17 |
---|---|
메모리 할당 (0) | 2015.01.15 |
데드락, Live락 대드락의 설명 (0) | 2014.08.08 |
java 와 c/c++의 차이 (0) | 2014.07.21 |
내가 추구하는, 비효율적이고 불합리한 게임개발. (0) | 2014.07.10 |