[완료] 오직 Map 파일과 Execution 파일로만 디버깅하기
글쓴이: goodssh / 작성시간: 목, 2012/07/05 - 10:45오전
DEBUGGING APPLICATION .NET AND WINDOWS 라는 책에선 MAP파일로 Crash point 를 얻어서 정확히 오류가 난 Line 을 찾아내는 섹션이 나옵니다.
해당 섹션을 Windows 7 x64 환경에서 실습해보기 위해 간단한 MFC 폼으로 할당되지 않은 포인터의 값을 지움으로써 crash를 냈습니다.
그러나 바로 crash point를 알려주는 메세지 박스는 뜨지 않고, 디버거를 연결시킬 수 있게 OS가 동작하더군요. VS2010 디버거를 연결하니 해당
crash point를 주긴 주는데...... 해당 주소가 정확한 주소가 아닙니다.
예를 들어,
Preferred load address is 00400000 의 load address가 설정되어있으면, 이 부분 근처의 주소값이 나와야 함에도 불구하고
실제 crash point가 0x775015de 이라는 황당한 값이 나옵니다. 알아보니, 0x775015de라는 주소는 윈도우 내부 라이브러리의 crash point라고 하네요.
실제로 map파일과 execution 파일로만 디버깅하는 것은 'turned out rather painful' 이라고도 하고...
정확하게 제가 만든 어플리케이션 안에서의 crash point를 얻을려면 어떻게 해야하나요?
아니면 현재의 최신 OS 디자인 방식으로는 이러한 exception을 처리하는 방법이 불가능한건가요?
Forums:
호출 stack 을 되짚어야 하는데...
말씀하신 정보로는 불가능합니다.
답변 감사합니다. '불가능'하다 라는 말씀은 현재
답변 감사합니다.
'불가능'하다 라는 말씀은 현재 OS 환경에선 불가능하단 말씀이신지, 아니면 애초에 불가능하단 말씀이신지 궁금합니다.
왜냐면, MAP 파일을 이용해서 Crash point로 디버깅하는 방법은 Codeproject 나 기타 국내저서에도 소개되는 방식이기 때문입니다...
모든 OS에서 불가능합니다.
아시는지 모르겠습니다만 우선 호출 stack(call stack)이란 호출된 함수들의 주소를 쌓아놓은 것을 말합니다.
이것은 함수가 호출될 때 먼저 기록하는 반환위치를 통해서 얻어집니다.
Debugger를 써보시면 흔히 보실 수 있습니다.
통상 함수 주소만이 아니라 매개변수를 함께 일컫기도 합니다.
이 호출 stack 이야말로 debugging에 가장 도움이 되는 정보일 겁니다.
이것은 runtime에 의해 결정되는 자료이고, 동적으로 계속 변하는 것이죠.
말씀하신 crach point는 crash가 났을 때의 위치이기 때문에 정적인 실행파일로는 그 시점의 호출 stack의 마지막 함수만을 확인할 수 있습니다.
그러니까 사용하고 있는 library에서 crash 가 나면 그 library 내부의 함수 밖에는 알 수가 없죠. 이것도 해당 library 가 MAP 을 제공할 때 만 가능한 것이고요.
책이나 web 에서 제공하는 자료는 말 그대로 crash 가 client programmer 가 작성한 source 에서 발생했을 때만 가능한 이야기입니다.
그렇기 때문에 crash가 난 시점에서 보통 memory dump(core dump)를 남깁니다. 이것은 process 가 점유하는 실행시점의 memory 를 말합니다.
이것을 활용하면 보통 호출 stack 을 모두 복구할 수 있습니다. 다만 C pointer(혹은 배열)을 잘못 써서
함수의 반환위치를 건드려 호출 stack 이 망가지면 복구가 불가능해질 수도 있습니다.
많은 양의 memory를 쓰는 process의 경우 dump를 남기기 애매할 경우, 호출 stack 만을 기록으로 남길 수도 있습니다.
답변 감사드립니다. 많은 참고가 되었습니다.
답변 감사드립니다.
많은 참고가 되었습니다.
댓글 달기