Debugging : 무언가 잘못 돌아갈 때 해야 할 일

 

[나는 실패한 것이 아니다. 작동하지 않는 10,000가지 방법을 발견했을 뿐이다] 에디슨

 

Debug는 bug를 잡는 일이다. bug는 의도하지 않은 동작을 의미한다.

 

<최초의 Bug>

<진공관 컴퓨터>

 

최초의 버그는 벌레는 의미했다. 컴퓨터가 진공관으로 이루어져 10진수로 연산을 하는 극악의 효율을 자랑하신 시절(에니악) 의도와 다르게 동작하는 컴퓨터의 문제를 해결하기 위해 진공관을 모두 검사했고, 그 결과 벌레를 찾아내어 해결한 사건이 debug의 시작이었다고 한다. 이 사건은 1945년 하버드 대학의 마크2 에어컨 릴레이 계산기에 대한 이야기다. 이는 기록이 남아있는 최초의 컴퓨터 버그이고, 1870년대 에디슨도 전기 회로에 있는 Bug에 대한 이야기를 했었다고 한다.

 

큰 관점에서 보면 compile error와 syntax error도 포함되지만 그런 것들을 컴파일러가 다 걸러주니, 진정한 버그는 기능 개발이 완료될 때까지도 발견되지 못한 오류라고 봐야 할 것이다.

 

Runtime Crash

보통 tombstone을 생성하고 죽는데 tombstone이 생겼다는 것 자체가 잘못된 동작의 증거이다.  보통은 segmentation fault가 많이 발생한다. 자주 만나는 crash는 다음과 같다.

Segmentation fault : 잘못된 메모리 접근, addr2line과 같은 툴의 도움을 받기도 한다.

Memory overrun : 보통 배열을 벗어나면 생기는데 Segmentation fault 귀결되는 경우가 많다.

runnging out of memory : 메모리 부족

memory leak : 메모리 누수, Embedded에서는 leak으로 인해 out of memory를 발생시키는 경우가 대부분이다. 이건 재현을 시기지 않고 잡기가 상당히 어렵다.

tombstone은 어디서 문제가 발생했는지 문제가 발생한 function call list를 보여주어 비교적 잡기 쉬운 편이다.

 

정말 잡기 어려운 일반적인 bug들에 대해서는 다음에 다시 이야기 하기로 하자.