디버그

3. 디버깅의 과정

디버깅은 일반적으로 다음과 같은 단계를 거친다.

1. 버그의 존재를 인식한다.

2. 버그의 발생원을 격리한다.

3. 버그의 원인을 특정한다.

4. 버그의 수정 방법을 결정한다.

5. 수정하고, 테스트한다.

오류가 프로그램을 이상 종료시킬 정도로 심각하거나, 프로그램이 문제를 감지하여 오류 또는 로그 메시지를 표시하면 버그의 존재를 명확히 인식할 수 있다. 그러나 오류가 경미하여 잘못된 결과를 내는 경우, 버그의 존재를 감지하기 어려울 수 있다.

디버깅의 첫 단계는 버그의 징후를 특정하는 것이다. 문제 징후, 발생 조건, 가능한 회피책 등을 관찰하는 것은 이후 디버깅에 큰 도움이 된다.

다음 단계는 시스템의 어떤 부분이 문제를 일으키는지 식별하는 것이다. 이는 디버깅에서 가장 어려운 단계 중 하나이며, 문제 발생 지점이 증상 출현 지점과 항상 일치하지는 않는다.

이 단계에서는 반복적인 소프트웨어 테스트가 필요할 수 있다. 프로그래머는 입력, 읽기, 처리 과정 등을 검증한다. 모듈화된 시스템에서는 모듈 간 인터페이스를 통해 주고받는 데이터의 타당성을 검사하여 단계를 쉽게 할 수 있다. 입력이 올바르고 출력이 그렇지 않다면, 오류 발생 원인은 해당 모듈 안에 있다. 반복적인 테스트를 통해 오류 발생 지점을 몇 줄의 코드까지 특정할 수 있다.

경험이 풍부한 프로그래머는 이전 경험을 바탕으로 문제 위치에 대한 가설을 세우고, 의심스러운 부분의 입력과 출력을 테스트한다. 이는 과학적 방법의 일종이다. 경험이 부족한 경우, 프로그램을 단계별로 실행하여 예상과 다른 지점을 찾는다. 어떤 변수에 주목할지 결정하는 것 또한 과학적 방법의 일종이다. 다른 접근 방식은 이진 탐색과 유사하게 처리 또는 데이터 흐름의 중앙 부근에서 테스트하여 오류 발생 위치를 좁혀나가는 것이다.

버그 위치를 찾았다면, 다음은 버그의 실제 원인을 밝혀내는 것이다. 여기에는 프로그램의 다른 부분 조사가 필요할 수 있다. 시스템을 잘 이해하는 것은 버그 원인 파악에 필수적이다. 숙련된 디버거는 문제 발생 위치를 파악할 수 있지만, 시스템에 정통한 사람만이 오류의 진정한 원인을 정확하게 찾을 수 있다.

버그 원인을 파악했다면, 코드 내 유사한 부분을 조사하여 실수가 반복되지 않았는지 확인하는 것이 좋다.

문제 해결의 근원을 파악했다면, 다음은 수정 방법을 결정하는 것이다. 단순한 문제가 아니라면 시스템에 대한 깊은 이해가 필수적이다. 수정으로 인해 예상치 못한 결과가 발생할 수 있으며, 기존 버그 수정으로 인해 새로운 버그가 발생하거나 숨겨진 버그가 드러날 수 있다.

상황에 따라 영구적인 수정 전에 "임시 수정(quick fix)"을 구현하는 것이 응급 처치로 바람직할 수 있다. 이는 문제의 긴급성, 발생 빈도, 부작용, 수정의 성격, 제품 일정 등을 고려하여 결정된다.

수정 후에는 시스템을 테스트하여 수정이 문제에 올바르게 대처하는지, 원치 않는 부작용을 일으키지 않는지 확인해야 한다.

규모가 큰 시스템에서는 회귀 테스트를 수행하는 것이 좋다.

4. 디버깅 기법

대화형 디버깅은 디버거 도구를 사용하여 프로그램 실행을 단계별로 처리하고, 상태를 검사하거나 변경하기 위해 일시 중지하는 기법이다. 서브루틴이나 함수 호출은 전체 속도로 실행되거나, 단계별로 실행될 수 있으며, 이러한 옵션들을 조합할 수도 있다. 오류가 의심되지 않는 코드는 전체 속도로 실행하고, 특정 지점에 중단점을 설치하여 실행을 멈출 수 있다. 반복 코드를 평가할 때는 프로그램 루프 끝에 중단점을 설정하는 것이 편리하다. 특정 변수가 변경될 때 실행을 진행하는 감시점과, 예외 또는 공유 라이브러리 로딩과 같은 특정 프로그램 이벤트에 디버거를 중지시키는 중단점도 일반적으로 사용 가능하다.
인쇄 디버깅(또는 printf 디버깅)은 추적문이나 인쇄문을 통해 프로세스의 실행 흐름과 데이터 진행 상황을 관찰하는 기법이다. 추적이라고도 한다. 추적은 특수 도구(GDB의 추적 등)를 사용하거나 소스 코드에 추적문을 삽입하여 수행할 수 있다. C에서는 printf 함수를 사용하기 때문에 printf 디버깅이라고도 한다. 초보자용 BASIC 프로그래밍 언어의 초기 버전에서는 TRON("Trace On"의 약자) 명령으로 이 기능을 켰다. TRON은 프로그램 실행 시 각 BASIC 명령 줄의 줄 번호를 출력했다.
활동 추적은 추적과 유사하지만, 한 번에 하나의 명령이나 함수 단위로 실행을 따르는 대신, 코드의 특정 부분을 실행하는 데 CPU가 소요한 시간을 기반으로 프로그램 활동을 추적한다. 이는 정의된 메모리 주소(머신 코드 프로그램) 또는 특정 프로그램 모듈(고수준 언어 또는 컴파일된 프로그램) 내에서 명령을 처리하는 데 걸리는 시간의 일부로 표시된다. 추적된 영역에서 프로그램 실행 시간의 과도한 부분이 소모되면, 잘못된 프로그램 로직으로 인한 프로세서 시간의 부적절한 할당이나, 최적화를 통해 개선될 수 있는 비효율적인 할당을 나타낼 수 있다.
원격 디버깅은 디버거와 다른 시스템에서 실행되는 프로그램을 디버깅하는 과정이다. 원격 디버깅을 시작하려면 디버거가 통신 링크(예: 로컬 영역 네트워크)를 통해 원격 시스템에 연결해야 한다. 그러면 디버거는 원격 시스템에서 프로그램의 실행을 제어하고 상태 정보를 검색할 수 있다.
사후 분석 디버깅은 프로그램이 충돌된 후의 디버깅이다. 로그 파일 검사, 충돌 시 호출 스택 출력,^[8] 메모리 덤프 (또는 코어 덤프) 분석과 같은 추적 기술이 포함된다. 프로세스 덤프는 시스템에 의해 자동(예: 처리되지 않은 예외로 프로세스가 종료된 경우), 프로그래머가 삽입한 명령, 또는 대화형 사용자에 의해 수동으로 얻을 수 있다.
"울프 펜스" 알고리즘: 에드워드 가우스는 1982년 Communications of the ACM 기사에서 이 알고리즘을 다음과 같이 설명했다. "알래스카에 늑대 한 마리가 있습니다. 어떻게 찾을 수 있습니까? 먼저 주 중간에 울타리를 만들고, 늑대가 울부짖을 때까지 기다린 다음 울타리의 어느 쪽에 있는지 확인합니다. 늑대가 보일 때까지 해당 측면에서만 과정을 반복합니다."^[9] Git 버전 관리 시스템에서는 ''git bisect'' 명령으로 구현되어, 특정 버그를 도입한 커밋을 결정하는 데 사용된다.
기록 및 재생 디버깅은 프로그램 실행 기록을 생성하는 기술이다(예: Mozilla의 무료 rr 디버깅 도구). 이를 재생하고 대화형으로 디버깅할 수 있다. 원격 디버깅 및 간헐적, 비결정적, 기타 재현하기 어려운 결함을 디버깅하는 데 유용하다.
시간 여행 디버깅은 프로그램 실행 중 발생하는 일을 이해하기 위해 소스 코드를 시간상 거꾸로 이동하는 과정이다(예: Undo LiveRecorder 사용). 사용자는 프로그램과 상호 작용하고, 원하는 경우 기록을 변경하고, 프로그램 반응을 볼 수 있다.
델타 디버깅은 테스트 케이스를 자동화하여 단순화하는 기술이다.^[10]
사프 스퀴즈는 실패하는 테스트의 일부를 점진적으로 인라인하여 테스트 내에서 실패를 격리하는 기술이다.^[11][12]
인과 관계 추적은 계산에서 원인-결과 체인을 추적하는 기술이다.^[13] 널 포인터 역참조와 같은 특정 버그에 맞게 조정할 수 있다.^[14]

5. 도구

디버거는 디버그를 돕는 도구이다. 디버거는 주로 원하는 코드에 중단점을 지정하여 프로그램 실행을 정지하고, 메모리에 저장된 값을 살펴보며, 실행을 재개하거나, 코드를 단계적으로 실행하는 등의 동작을 한다. 고급 디버거들은 메모리 충돌 감지, 메모리 누수 감지, 다중 스레드 관리 등의 기능도 지원한다.^{[25][26][27][28]}

6. 안티 디버깅

안티 디버깅(Anti-Debugging)은 디버깅을 방해하고 분석을 방해하는 기술이다.^[19] 디버깅을 당하면 해당 디버거 프로그램을 종료시키거나 에러를 발생시키는 등 다양한 방법을 사용하여 분석을 방해한다. 안티 디버깅 기술에는 수많은 방법이 존재하며 발전하고 있으며, 이에 따라 이를 우회하는 기술도 계속 발전하고 있다.

이는 복제 방지 방식에서 공인된 배포자가 적극적으로 사용하지만, 악성코드가 탐지 및 제거를 복잡하게 만들기 위해서도 사용된다.^[20] 안티 디버깅에 사용되는 기술에는 다음과 같은 것들이 있다.

• API 기반: 시스템 정보를 사용하여 디버거의 존재 여부를 확인
• 예외 기반: 예외가 간섭되는지 확인
• 프로세스 및 스레드 블록: 프로세스 및 스레드 블록이 조작되었는지 확인
• 수정된 코드: 소프트웨어 중단점을 처리하는 디버거에 의해 이루어진 코드 수정을 확인
• 하드웨어 및 레지스터 기반: 하드웨어 중단점 및 CPU 레지스터 확인
• 타이밍 및 지연 시간: 명령어 실행에 걸리는 시간 확인
• 디버거 감지 및 불이익^[20]

7. 임베디드 시스템 디버깅

임베디드 시스템 환경은 개발자가 사용할 수 있는 플랫폼(CPU 아키텍처, 공급업체, 운영 체제 및 그 변형)이 매우 다양하다는 특징을 가진다. 임베디드 시스템은 범용으로 설계되지 않고, 특정 작업(또는 제한된 범위의 작업)을 위해 개발되며, 플랫폼은 해당 애플리케이션을 최적화하기 위해 특별히 선택된다. 이러한 점은 임베디드 시스템 개발자에게 어려움을 줄 뿐만 아니라, 플랫폼마다 다른 디버깅 도구가 필요하므로 시스템 디버깅 및 테스트를 더욱 어렵게 만든다.

이러한 이질성에도 불구하고, 상업적으로 개발된 디버거와 연구용 프로토타입이 존재한다. 상업용 솔루션으로는 그린힐스 소프트웨어^[15], 라우터바흐 GmbH^[16] 등이 있다. 연구용 프로토타입 도구로는 Aveksha^[17]와 Flocklab^[18]이 있다. 이들은 모두 표준 JTAG 인터페이스를 통해 신호를 주고받는 저비용 임베디드 프로세서에서 사용할 수 있는 온칩 디버그 모듈(OCDM)을 활용한다.

8. 자동 버그 수정

참조

_[1] 웹사이트 InfoWorld Oct 5, 1981 https://books.google[...] 1981-10-05
_[2] 웹사이트 Archived copy https://bancroft.ber[...]
_[3] 간행물 The Diagnosis of Mistakes in Programmes on the EDSAC https://www.jstor.or[...] 1951-05-22
_[4] 간행물 Evolution of automatic computation https://dl.acm.org/c[...] 1952
_[5] 간행물 Solution of systems of linear inequalities on a digital computer https://dl.acm.org/c[...] 1952
_[6] 간행물 MANIAC https://dl.acm.org/c[...]
_[7] 문서 The Compatible Time-Sharing System http://www.bitsavers[...] M.I.T. Press 1963
_[8] 웹사이트 Postmortem Debugging https://www.drdobbs.[...]
_[9] 논문 Pracniques: The 'Wolf Fence' Algorithm for Debugging https://dl.acm.org/c[...]
_[10] 서적 Why Programs Fail: A Guide to Systematic Debugging Morgan Kaufmann 2005
_[11] 웹사이트 Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze http://www.threerive[...]
_[12] 웹사이트 The Saff Squeeze https://blog.thecode[...] 2022-03-28
_[13] 논문 Isolating cause-effect chains from computer programs 2002-11-01
_[14] 서적 Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07
_[15] 웹사이트 SuperTrace Probe hardware debugger https://www.ghs.com/[...]
_[16] 웹사이트 Debugger and real-time trace tools https://www.lauterba[...]
_[17] 서적 Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems ACM 2011
_[18] 서적 Proceedings of the 12th international conference on Information processing in sensor networks ACM 2013
_[19] 웹사이트 Anti-Debugging Series – Part I https://www.veracode[...] 2008-12-02
_[20] 웹사이트 Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh http://people.seas.h[...]
_[21] 서적 Security Engineering https://archive.org/[...] Wiley 2001-03-23
_[22] 웹사이트 Microsoft Word for DOS 1.15 http://toastytech.co[...]
_[23] 웹사이트 de-の意味・使い方｜英辞郎 on the WEB https://eow.alc.co.j[...]
_[24] 웹사이트 bug http://www.catb.org/[...] 2003-12-29
_[25] 웹사이트 Compiler Warning (level 1 and level 4) C4700 | Microsoft Learn https://learn.micros[...]
_[26] 웹사이트 Diagnostic flags in Clang — Clang git documentation https://clang.llvm.o[...]
_[27] 웹사이트 Annotating function parameters and return values | Microsoft Learn https://learn.micros[...]
_[28] 웹사이트 Attributes in Clang — Clang git documentation https://clang.llvm.o[...]
_[29] 서적 순서도 작성 정익사
_[30] 웹사이트 InfoWorld Oct 5, 1981 https://books.google[...]