CppDebuggingTips

UserPreferences

1. 메모리 디버그 코드
2. 간단한 컴파일 타임 어서트
3. 스택 오버플로우 발생시 덤프 기록하기
4. 생성자 및 소멸자 내부에서는 가상 함수가 제대로 호출되지 않는다
5. 디버깅을 위한 자잘한 함수들 (Visual C++)
6. 스레드에 이름 붙이기 (Visual C++)
7. Critical Section에 락을 건 스레드 알아내기 (Visual C++)
1. 순서
2. 알아둘 점
8. 콜스택이 나오지 않거나 이상한 경우 (Visual C++)
1. 디버그 심볼이 없는 경우
2. 잘못된 OS 심볼
3. 어셈블리어로 만들어진 함수
4. 스택 자체가 오염된 경우
5. 잘못된 ESP/EIP 레지스터 값
6. 함수 합치기 (Linker COMDAT folding)
9. 예외를 만들지 않고, 그냥 사라지는 프로세스 (Visual C++)
1. 잘못된 예외 처리
1. try-except 구문에서 예외 필터 부분 안에서 예외를 던지는 경우
2. 잘못된 예외 처리 핸들러를 설정한 경우
3. 스택 오버플로우를 잘못 처리하는 경우
4. 무한 루프
2. 정상적인 프로세스 종료
10. 에러코드 문자열로 변환하기
11. 링크

1 메모리 디버그 코드

VisualCpp 메모리 코드



값	의미
0xCD, 0xCDCDCDCD	최초로 할당된 메모리
0xFD, 0xFDFDFDFD	유저가 할당한 메모리 뒤에 붙는 바운드 체크용 메모리
0xDD, 0xDDDDDDDD	삭제된 메모리. _CRTDBG_DELAY_FREE_MEM_DF 플래그 값이다.
0xCC, 0xCCCCCCCC	초기화되지 않은 지역 변수. /GX 옵션을 켜야 한다.
0xABABABAB	LocalAlloc 함수로 할당한 메모리 뒤에 붙는 바운드 체크용 메모리
0xBAADF00D	LocalAlloc 함수로 할당한 메모리
0xFEEEFEEE	HeapAlloc 함수를 위해 확보는 해놨으나, 아직 실제로 할당되지는 않은 메모리. 또는 HeapFree 함수를 통해 해제된 메모리

2 간단한 컴파일 타임 어서트

#if defined (NDEBUG)
    #define StaticAssert(expr) ((void)0)
#else
    template <bool T> struct ASSERT_STRUCT {};
    struct ASSERT_STRUCT<true> { static void static_assertion_failed() {} };
    #define StaticAssert(expr) { const bool __b = (expr) ? true : false; ASSERT_STRUCT<__b>::static_assertion_failed(); }
#endif

VisualCpp 8.0 경우에는 템플릿 특수화 방식이 약간 변경되었다.


template <bool T> struct ASSERT_STRUCT {};
template<> struct ASSERT_STRUCT<true> { static void static_assertion_failed() {} };

3 스택 오버플로우 발생시 덤프 기록하기

스택 오버플로우 발생시의 덤프 기록은 약간 다르게 처리를 해줘야한다. 어려운 건 아니고, 그냥 다른 스레드를 하나 생성해서 그쪽으로 스레드 핸들과 예외 포인터를 넘겨서 덤프를 기록하면 된다. 현재 스레드에서는 덤프 함수를 호출할 스택마저 모자랄 수 있기 때문이다. 하지만 다른 스레드를 하나 따로 생성하면 새로 생성한 스레드에서는 스택 공간이 충분하기 때문에 덤프를 무사히 기록할 수 있는 것이다. (스택은 스레드별로 유지되니까...)


typedef struct _DUMP_PARAMETER
{
    HANDLE              Thread;
    PEXCEPTION_POINTERS ExPtrs;
} DUMP_PARAMETER, *PDUMP_PARAMETER;

DWORD WINAPI WriteDump(LPVOID param)
{
    PDUMP_PARAMETER dumpParam = reinterpret_cast<PDUMP_PARAMETER>(param);
    ...여기서 실제 덤프를 수행...
}

LONG WINAPI HandleException(PEXCEPTION_POINTERS exPtrs)
{
    if (exPtrs)
    {
        PDUMP_PARAMETER dumpParam = (PDUMP_PARAMETER)malloc(sizeof(DUMP_PARAMETER));
        dumpParam->Thread = GetCurrentThread();
        dumpParam->ExPtrs = exPtrs;
        if (exPtrs->ExceptionRecord->ExceptionCode != EXCEPTION_STACK_OVERFLOW)
        {
            WriteDump(dumpParam);
        }
        else // 스택 오버플로 발생 시에는 별도의 스레드를 생성해서 덤프를 기록한다.
        {
            HANDLE hThread = CreateThread(NULL, 102400, WriteDump, dumpParam, 0, NULL);
            WaitForSingleObject(hThread, INFINITE);
            CloseHandle(hThread);
        }
    }
    return EXCEPTION_EXECUTE_HANDLER;
}

void main()
{
    ...
    // 예외 처리 핸들러를 설정한다.
    SetUnhandledExceptionFilter(HandleException);
    ...
}

4 생성자 및 소멸자 내부에서는 가상 함수가 제대로 호출되지 않는다

vtable이 완전히 설정된 상태가 아니기 때문이다. 나쁜 프로그래밍 방법이므로 다른 방법을 사용하는 것이 좋다.

샘플


#include <iostream>
using namespace std;

class base
{
public:
    base() { function(); }
    virtual void function() { cout << "i'm base" << endl; }
};

class derived : public base
{
public:
    derived() { }
    virtual void function() { cout << "i'm derived" << endl; }
};

int main()
{
    derived d;
    return 0;
}

출력


i'm base 

5 디버깅을 위한 자잘한 함수들 (Visual C++)

CRT 시리즈는 제외. 음... 적어놓고 보니 꽤 많은데... -_-



함수	설명
_set_new_handler	동적 메모리 할당이 실패했을 때 호출되는 콜백 함수를 설정한다.
_set_new_mode	malloc 함수가 실패했을 때 _set_new_handler에서 설정한 함수를 호출할 것인가의 여부를 반환한다.
set_terminate	처리되지 않은 예외로 인해 프로그램이 종료될 때 호출할 함수를 설정한다.
set_unexpected	처리되지 않은 예외가 발생했을 때 호출할 함수를 설정한다.
uncaught_exception	???
_set_error_mode	에러 발생시 메시지 출력되는 곳(콘솔화면 또는 메시지박스)을 설정한다.
_set_purecall_handler	순수 가상 함수가 호출되었을 때 호출할 콜백 함수를 설정한다.
_set_sbh_threshold	Small Block Heap에 할당되는 메모리의 최대양을 설정한다.
_set_se_translator	Win32 Structured Exception을 C++ Exception으로 처리 가능하게 한다. 자세한 것은 StructuredExceptionAsCppException 페이지를 참고.
_set_security_error_handler	BufferOverrun이 발생했을 때 호출할 콜백 함수를 설정한다.
_setmaxstdio	동시에 열 수 있는 최대 파일 갯수를 설정한다. ulimit와 비슷하다.
_matherr	math.h 함수 실행 에러 발생시 호출되는 함수(?)
_fpieee_flt	IEEE 부동 소수점 연산 예외 발생시 호출되는 함수를 설정한다.
atexit	메인 함수가 반환된 후 호출되는 함수를 설정한다

6 스레드에 이름 붙이기 (Visual C++)

from Setting a Thread Name (Unmanaged)


//
// Usage: SetThreadName (-1, "MainThread");
//
typedef struct tagTHREADNAME_INFO
{
    DWORD dwType; // must be 0x1000
    LPCSTR szName; // pointer to name (in user addr space)
    DWORD dwThreadID; // thread ID (-1=caller thread)
    DWORD dwFlags; // reserved for future use, must be zero
} THREADNAME_INFO;

void SetThreadName( DWORD dwThreadID, LPCSTR szThreadName)
{
    THREADNAME_INFO info;
    info.dwType = 0x1000;
    info.szName = szThreadName;
    info.dwThreadID = dwThreadID;
    info.dwFlags = 0;

    __try
    {
        RaiseException( 0x406D1388, 0, sizeof(info)/sizeof(DWORD), (DWORD*)&info );
    }
    __except(EXCEPTION_CONTINUE_EXECUTION)
    {
    }
}

SetThreadName 함수를 스레드 메인 루프 제일 위쪽(즉 스레드 ID를 할당 받고난 후)에서 호출해 주면, 스레드창에 스레드 이름들이 출력되는 것을 볼 수 있다. 스레드 이름 없어도 스레드 함수로 대부분 어느 스레드인지를 알 수 있기는 하지만... 참고로 디버거가 붙어있는 상태에서만 동작한다. IsDebuggerPresent 함수를 이용해서 디버거가 붙어있는 경우에만 이름을 설정하자.

7 Critical Section에 락을 건 스레드 알아내기 (Visual C++)

from How to find the owner of a critical section



7.1 순서

1. 심볼 설치는 필수. DrWatson 페이지를 참고.
   
2. 아무 곳이나 브레이크 포인트를 설정해서 실행을 일시 중지시킨다.
   
3. 도구 모음 -> 디버그 위치 -> 스레드 메뉴를 이용해 락을 걸려 하고 있는 스레드를 찾아낸다. (EnterCriticalSection 함수에 멈춰있는 스레드가 있을 것이다.)
   
4. 락을 걸려 하는 스레드를 찾았다면 콜스택을 표시한다. 대강 아래와 같은 모양의 콜스택이 출력될 것이 다.
   

   NTDLL.DLL!_NtWaitForSingleObject@12()  + 0xb     
   NTDLL.DLL!_RtlpWaitForCriticalSection@4()  + 0x74    
   NTDLL.DLL!_RtlEnterCriticalSection@4()  + 0x91f5     
   GameServerD.exe!BasicCriticalSection::enter()  줄 41 + 0xf  C++ 
   GameServerD.exe!CriticalSection::lock(...) const 줄 94  C++ 
   GameServerD.exe!DeadlockTestThread::run()  줄 135 + 0x27    C++ 
   GameServerD.exe!thread_func_proxy(void * pContext=0x0012feb4)  줄 41 + 0xd  C++ 
   GameServerD.exe!_threadstartex(void * ptd=0x00e45300)  줄 241 + 0xd C 
   KERNEL32.DLL!77e5b382()      
   NTDLL.DLL!_RtlAllocateHeapSlowly@12()  + 0x14acd     
   

5. 콜스택에서 NTDLL.DLL!_RtlEnterCriticalSection@4() 프레임으로 간다.
   
6. 디버그 -> 창 -> 메모리 메뉴를 이용해 메모리 윈도우를 띄운다.
   
7. 메모리 윈도우 컨텍스트 메뉴를 이용해서 출력을 4바이트 정수, 표시를 16진수로 한다.
   
8. 메모리 윈도우의 주소창에서 '@vframe'이라고 입력한다.
   
9. 제일 첫번째 4바이트 정수 값이 함수의 리턴 위치다. 두번째 4바이트 정수값이 크리티컬 섹션의 위치다. 이 값을 카피해서 메모리 윈도우의 주소창에다 입력한다.
   
10. 앞에서 네번째의 4바이트 정수가 크리티컬 섹션에 락을 건 스레드의 ID다. 조사식 윈도우에서 값을 표시해 보면, 스레드 목록에 일치하는 스레드가 있을 것이다.
    
    

7.2 알아둘 점

• @vframe이 제대로 표시되지 않는 경우가 있는데, 이는 콜스택 자체가 잘못 출력되고 있다는 말이다.
  
• 콜스택이 제대로 나오는 상태라면, 메모리 윈도우를 띄울 필요 없이 조사식에서 다음과 같이 입력하면 스레드 ID가 출력된다.
  

  *((unsigned int*)(*(unsigned int*)(@vframe+4))+3) 
  

  
  
  

8 콜스택이 나오지 않거나 이상한 경우 (Visual C++)

from Bad Native Callstacks



8.1 디버그 심볼이 없는 경우

더 이상 말할 가치가 있는가?



8.2 잘못된 OS 심볼

VC6과 VC7은 심볼 파일의 형식이 약간 다른데, 기본적으로 마이크로소프트에서 배포하는 심볼은 VC6 형식이다. OS와 밀접하게 관련되어 있는 프로그램일 경우 문제가 된다.



8.3 어셈블리어로 만들어진 함수

어셈블리어로 프로그램을 제작하는 경우, 디버거가 상당히 혼란을 겪게 된다. 기본 C 런타임이 대표적인 예이다.



8.4 스택 자체가 오염된 경우

스택 오버플로우 등의 이유로 인해 콜스택 데이터 자체가 날아가버린 경우다. 이 경우 메모리 쪽으로 버그를 찾을 것이 아니라, C 런타임 함수를 사용하거나, 컴파일할 때 '/gs' 플래그를 주는 것이 좋다.



8.5 잘못된 ESP/EIP 레지스터 값

이는 코드가 쓰레기값을 실행하기 시작할 때 발생한다. 삭제된 객체의 vtable을 참조하거나, 잘못된 함수 포인터를 사용하는 경우가 대표적이라고 할 수 있다. 잘못된 타입 캐스트도 원인이 될 수 있다.

Debugging Tools for Windows에 딸려오는 gflags.exe를 이용해 Page Heap 옵션을 켠 다음, WinDbg를 이용해 디버그하기 바란다. (VisualCpp 디버거로는 안 잡힌다.)

Page Heap 옵션에 관해서는 PageHeap 문서를 참고하면 된다. pageheap.exe 어쩌구 저쩌구 하는 건 무시하고, 그냥 gflags.exe를 이용하기만 하면 된다.



8.6 함수 합치기 (Linker COMDAT folding)

두 함수가 완전히 같은 머신 코드를 생성하는 경우, 컴파일러가 이를 하나로 합치는 경우가 있다. 함수 이름이 틀리니, 디버거가 혼란을 일으킬 수 밖에 없다. 최적화를 끄고 테스트해보기 바란다.

9 예외를 만들지 않고, 그냥 사라지는 프로세스 (Visual C++)

from Why a process vanishes



9.1 잘못된 예외 처리

SEH 부분을 보면 알겠지만, 예외 처리를 잘못하는 경우, OS가 JIT 디버거를 띄울 기회를 얻지 못할 수도 있다.



9.1.1 try-except 구문에서 예외 필터 부분 안에서 예외를 던지는 경우

다음과 같은 코드를 컴파일해보시라.


DWORD check() 
{ 
    throw 333; 
    return EXCEPTION_EXECUTE_HANDLER; 
} 
 
void main() 
{ 
    __try 
    { 
        int* p = NULL; 
        *p = 444; 
    } 
    __except(check()) // 필터 안에서 예외가 발생한다. 
    { 
        throw 111; 
    } 
} 

디버거를 붙인 상태로 실행하면 예외 처리가 가능하겠지만, 그냥 실행하면 아무 말도 하지 않고 사라지는 것을 볼 수 있을 것이다.



9.1.2 잘못된 예외 처리 핸들러를 설정한 경우

SetUnhandledExceptionFilter, AddVectoredExceptionHandler, _set_se_translator 함수를 이용해서 예외 처리 핸들러를 설정할 수 있다. 핸들러가 잘못 짰다면 OS에게 기회가 오지 않을 수 있다. DLL이 로드되면서 자동으로 예외 처리 핸들러를 설정하는 경우, 이런 문제가 자주 발생한다. Windows Server 2003의 경우, SafeSEH 리스트에 없는 핸들러를 수동으로 설정하려는 경우, 발생한다.



9.1.3 스택 오버플로우를 잘못 처리하는 경우

스택 오버플로우가 발생하는 경우, 스택의 끝에 있는 가드 페이지(guard page)가 없어진다. 예외 필터에서 스택 오버플로우 예외를 잡았다면, 가드 페이지도 재설정해줘야 한다. 가드 페이지를 재설정해 주지 않으면, 다음 스택 오버 플로우 시에 프로세스가 그냥 사라지게 된다.



9.1.4 무한 루프

익셉션 핸들러 자체를 가비지로 덮어쓴 경우



9.2 정상적인 프로세스 종료

TerminateProcess, ExitProcess, TerminateThread, ExitThread 등의 함수를 사용해서 프로그램을 종료한 경우, OS는 이를 정상적인 동작으로 취급한다.

10 에러코드 문자열로 변환하기

별 건 아니다만...


/// \brief 에러 코드를 문자열로 변환해서 리턴한다.
std::string Error2String(unsigned int errorCode)
{
    LPVOID msgBuf = NULL;
    std::string message = "Error2String() call failed!";

    if (::FormatMessage(
        FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
        NULL, 
        errorCode, 
        //MAKELANGID(LANG_KOREAN, SUBLANG_KOREAN),
        MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),
        (LPTSTR)&msgBuf,
        0,
        NULL))
    {
        message = reinterpret_cast<LPCTSTR>(msgBuf);
        ::LocalFree(msgBuf);
    }

    return message;
}

/// \brief GetLastError() + Error2String()
std::string GetLastErrorString()
{
    return Error2String(::GetLastError());
}

11 링크

• Retail code debugging
  
• Debugger Type = Auto for C++ projects
  
• Breaking when a module loads
  
• Adding a function to the safeseh list
  
• Diagnosing 'The debugger is not properly installed'
  
• Configuring XP SP2 to enable remote debugging for VS 2002/2003
  
• Debugging the last COM Error (SetErrorInfo/GetErrorInfo)
  
  
• Debugging application startup when you don't directly launch the app
  
• Inside 'Image File Execution Options' debugging
  

• CategoryDebugging