| |||||||||
| [디버깅] 데이타 브레이크포인트 | Win32 / MFC | 2005/12/13 10:39 |
| http://blog.naver.com/drrich/20019987593 | |
| 데이타 브레이크포인트 Written by 이동우 Visual C++에서 브포를 거는 방법은 크게 세가지다.
예를 들어보자. MFC에서 Dialog base로 프로젝트를 하나 생성한다. 그리고 어플리케이션 코드에 다음과 같이 전역변수 3개를 선언한다. down.cpp ///////////////////////////////////////////////////////////////////////////// // CDownApp int g_n = 0; // Global변수 3개를 선언했다. char g_szExeName[10]; CString g_strContent; BEGIN_MESSAGE_MAP(CDownApp, CWinApp) //{{AFX_MSG_MAP(CDownApp) ON_COMMAND(ID_APP_ABOUT, OnAppAbout) // NOTE - the ClassWizard will add and remove mapping macros here. 그리고 메인 프레임 윈도우가 생성이 되면 g_szExeName변수에 자신의 파일네임을 얻어오도록 한다. CMainFrame클래스의 OnCreate함수내에 GetModuleFileName함수 호출코드를 삽입한다. // TODO: Delete these three lines if you don't want the toolbar to // be dockable m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY); EnableDocking(CBRS_ALIGN_ANY); DockControlBar(&m_wndToolBar); ::GetModuleFileName (NULL, g_szExeName, MAX_PATH); // 디버깅 예제 이제 class wizerd에서 마우스 왼쪽 버튼이 눌리면 발생하는 메시지인 WM_LBUTTONDOWN을 view클래스에서 잡도록하고 핸들러를 등록한다. DownView.cpp ///////////////////////////////////////////////////////////////////////////// // CDownView message handlers void CDownView::OnLButtonDown(UINT nFlags, CPoint point) { // TODO: Add your message handler code here and/or call default if (!g_n) ::AfxMessageBox (_T("Click test...")); CView::OnLButtonDown(nFlags, point); } 자, 준비는 여기서 끝났다. 언듯 보기에 버그가 없는 코드로 보일 것이다. 그러나 실제로 빌드해서 실행해보면, 왼쪽 마우스 버튼을 눌러도 view에 아무 것도 뜨지 않을 것이다. 분명 핸들러에는 왼쪽 마우스가 눌리면 "Clck test..."라는 메시지 박스가 떠야하는데 아무런 동작을 안하니 어딘가에 버그가 숨어있다고 봐야한다. 위의 코드에서 if(!g_n)에 브포를 걸고 g_n변수를 추적해보면, 앗~ 어찌된 일인지 핸들러 내부에 들어올 때부터 g_n에 이상한 값이 들어가 있다. 그런데 g_n을 선언할 때 0을 할당한 곳 외에 코드 어디에도 g_n을 바꾸는 부분이 없다. 그럼 이후에 대체 어디에 브포를 걸어야 할까? 이처럼 버그의 원인이 특정한 위치라기보다는 변수에 연관된 로직버그일 때는 로케이션 브포만 가지고서는 쉽게 추적이 안될 때가 있다.(물론 위치 브포만 가지고도 불가능한 것은 아니지만 더 시간이 들도 고생도 더 해서 찾게된다) 이때 데이타 브포의 기능을 이용하면 쉽게 디버깅을 할 수 있다. 먼저, 특정 이벤트에 반응을 하지 않으므로 해당 이벤트 핸들러에서 시작해보자. 이 예에서 주된 관심사는 대체 어디에서 g_n의 값을 바꾸냐이다. if(!g_n)문장에 브포를 걸고 variable window에서 &g_n을 입력해 g_n변수의 주소를 알아낸다.  g_n의 주소가 0x4178f8번지라는 것을 확인할 수 있다. 자 이제 여기의 브포는 해제하자. 그리고 우리 프로그램이 메모리에 로드되고 나서 이 주소의 내용이 언제 바뀌는지 알아보면 된다. 먼저 버그가 숨어있는 프로그램이 메모리에 로드되고 나서 처음 진입하는 엔트리 포인트에 브포를 걸어야 한다. 어플리케이션 코드내 InitInstance가 적당할 것이다. 이 함수의 첫번째 라인인 AfxEnableControlContainer()에 브포를 걸자. 그리고 디버그 모드로 실행한다. AfxEnableControlContainer()에 브포가 걸리면, Edit메뉴에서 Breakpoint를 선택해서 브레이크포인트 대화상자를 연다. Data탭을 선택하고 Enter the expression to be evauated란에 위에서 알아낸 주소를 이용해 다음과 같이 입력한다.  위 문장의 의미는 0x4178f8번지 내용이 0이 아닐 때 브레이크를 건다는 의미이다. 참고로 데이타 브포를 걸 땐 다음과 같은 방법으로 브포를 지정해준다. *((type*) address) condition 자, 브레이크를 걸었으면 go하자. 그럼 다음과 같이 브포가 걸리는 것을 확인 할 수 있다.  콜스택을 보면 g_n의 값이 바뀐 위치가 ntdll내부이다. 그럼 ntdll내에 버그가 있어 사용자 데이타를 바꾸는걸까? ntdll내부에서 g_n의 값을 바꾸는 것은 맞지만 ntdll의 버그는 아니다. 이때 기본적으로 OS코드 내부는 이상이 없고 시스템콜 함수를 호출하는 유저코드의 파라미터에 문제가 있다는 것으로 생각해야 한다. 그럼 시스템콜 함수를 호출하는 가장 마지막 함수가 용의선상에 오른다. 콜스택에서 CMainFrame클래스의 OnCreate에서 OS시스템으로 진입했음을 확인 할 수 있다. 거기를 클릭해보자.  빙고! 찾았다. GetModuleFileName를 호출한 이후로 g_n의 값이 변경된걸 봐서 이 함수에 넘기는 인자에 문제가 있었던 것이다. 결론을 말하자면, 파일네임 버퍼인 g_szExeName의 크기를 10바이트로 잡고 MAX_PATH(256바이트)의 크기로 파일네임을 읽어오기 때문에 overflow가 발생해서 메모리 침범이 발생했던 것이다. 이처럼 위치를 추론할 수 없어 로케이션 브포를 사용하기 어려운 버그에 데이타 브레이크포인트를 이용하면 쉽게 버그의 위치를 찾아낼 수 있다.보통 변수나 특정 메모리 영역이 원인을 모른채 깨질 때 유용한 방법이다. Visual C++을 많이 사용해본 사람이라면 "그냥 'g_n != 0'이라고 쓰면 될 걸 왜 저렇게 어렵게 쓸까"라는 의문점이 들 것이다. 그러나 그 방법은 전역변수에서만 이용될 수 있으며 만약 로칼변수라면 해당 변수가 쓰인 로칼함수 내에서 유효하다. 만약 함수내에 다른 함수를 콜하면 변수이름은 의미가 없기 때문에 브포가 안걸린다. 그러나 위에서처럼 직접 메모리 주소를 쓰면 로칼이든 전역, 정적, 스택영역등 메모리 전 영역에서 모두 유효하게 되는 것이다. | |
댓글
댓글 쓰기