U.Seung's Log

 Linux에서 Daemon을 돌리다 보면 버그로 인해서 프로그램이 Crash 되는 일이 종종 있습니다.
 당연히 문제가 되는 부분 찾아서 고쳐야 합니다.

 그럴때 대부분 사용하는 방법이 Process가 죽기전에 기록을 Core파일에 남기도록 설정 하는 방법 입니다.
 정상적으로 남겨진 Core파일 경우라면 디버깅 하는게 큰 문제는 없을 테지만
 아래와 같이 콜스택이 깨져 보이는 난감한 상황을 만들어 내기도 합니다.



 콜스택이 깨져 보이는 경우는 주로 Stack Buffer Overrun 으로 인한 문제 입니다.
 (다른 문제는 이 글에서 다루지 않습니다.)
 이 경우, 스택에 있던 Return Address가 지워져 있기 때문에 GDB는 콜스택을 표시하지 못합니다.

 하지만 이런 경우라고 해서 너무 낙심할 것은 아닙니다.
 Stack Buffer가 조금 넘친 경우에는 남은 정보를 이용해서 문제를 해결 할 수 있기 때문입니다.

 이때, 실마리를 제공해주는 것은 Register의 ESP 입니다.
 비록 원하던 Return Adress는 지워졌지만 ESP는 값은 정상적인 값을 유지하고 있습니다.
 이제 ESP가 가르키던 메모리 주변을 뒤져서 Return Address와 유사한 값들이 있는지 찾아보면 문제에 대한 힌트를 얻을 수 있습니다.

 일단 Return Address랑 유사한 녀석들은 어떤 녀석이어야 하는지 파악 해야 합니다.
 당연히 Return Address는 실행가능한 Instruction 들이 저장되어 있는 Code Segment를 가르키고 있습니다. GDB에서는 maint info sections .text 명령어를 통해서 Code Segment를 찾아 볼 수 있습니다.



 이제 Code Segment의 범위도 구했으니 ESP를 기준으로 주변 탐색해서 Return Address와 유사한 녀석들을 찾아 본다면 아마 콜스택과 유사한 모양이 만들어 질 수 있을 겁니다.

 이를 위해서 간단한 User-defined Command를 만들었습니다.


 가독성이 다소 떨어지긴 하지만 동작은 간단합니다.
 주어진 범위를 탐색하면서 정해진 범위의 값(Code Segment의 범위)이 들어오면..
 해당 값을 info symbol 을 이용해서 출력하는 Command 입니다.



 실제로 사용하면 아래와 같은 결과를 얻을 수 있습니다. (함수 이름은 가명..)



콜스택(?)을 얻었으니 ESP값과 비교 등을 통해서 어느 지점에서 Crash되었는 지를 파악할 수 있을 것입니다. 아마 있어야 하는 함수 1~2개가 누락되어서 보이는 경우가 대부분 일테고요. 어떤 함수가 버퍼를 넘치게 했는지 찾아내면 됩니다.

좀 더 정확한 원인을 얻어 보기 위해서는 GDB의 x 명령어 등을 이용해서 ESP 주변 메모리를 잘 뒤져보면 답을 찾을 수 있습니다. 하지만 이 정도 까지 얻었다면 소스를 보고 문제의 원인을 먼저 찾고 문제점이 맞는지 검증하는 편이 더 빠를 수 있습니다.

그럼 즐거운 디버깅 되세요 :)