core 파일과 gdb 사용은 메모리(flash/ram)가 많은 시스템에서는 사용가능하지만, 그 크기를 무시할 수 없고 라이브러리 의존성도 약간 가지고 있습니다.  실제로 Sentry24NT 에는  dev 모드일 경우  루트파일 시스템에 추가 할수 있지만, 실제 배포하는 루트파일 시스템에는 추가 되어있지 않습니다. 하지만 메모리 침범이나 스택 overflow 등의 데이터에 대한 디버깅이 필요한 경우 gdb는 유용하게 쓰이는 툴입니다.

위의 경우가 아닌 코드 흐름상의 디버깅만에 필요하다면 strace 를 이용하면 유용합니다.

strace는 시스템 콜을 추적해 주는 툴입니다.  라이브러리 의존성이 적고, 크기가 작아 NT 장비에서는 기본으로 추가 되어 있습니다. 제 경우는 이 도구를 이용하여  아래와 같은 디버깅을 수행합니다.

• mutex  locking
• 시스템 block 위치 추적
• cpu 점유율이 상대적으로 높은 원인 파악
• 시스템 콜의 파리미터와 리턴값 확인
• 파일 입출력등 IO에 관련된 부분 확인

실제 오동작하는 장비에서 strace 정보 만으로도 많은 프로그램의 상태를 확인할 수 있어 빠른 디버깅과 문제 파악에 도움이 됩니다.

사용방법은 간단하여 “strace 프로그래 이름”, “strace -p 프로세스 번호”  를 이용하면 호출된 시스템 콜 정보를 확인할 수 있습니다.

• -c : 반복횟수, 지정횟수 이후 strace 프로그램 종료
• -d : 디버그 모드
• -i : 명령어 실행 주소를 보여줌
• -T : 시스템 콜 수행 시간을 보여줌
• -0 : 메시지 저장 파일을 지정함

Man Page 에는 더 많은 옵션이 있으나  개인적으로 주로 사용하는 옵션을 정리합니다.

strace 명령어 실행시

open ("/etc/nettrans.conf", O_RDONLY|O_LARGEFILE) = 3

와 같이 파리미터와 리턴값을 보여 줍니다.

open ("/etc/nettrans.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

처럼 시스템콜 리턴값으로 에러를 확인하는 용도로 사용가능합니다.

mutex 를 이용하는 경우 lock이 두번 호출되는 이중락 부분과 unlock 되지 않고 계속 기다리는 상태등을 확인 할 수 있습니다.

프로세스가 살아 있는 상태에서 확인이 가능하므로 개인적으로 프로그램의 상태를 확인하는 제일 먼저 수행해 보는 툴로서 NT 디버깅에 많은 도움이 되는 툴입니다.