디버깅

Debugging
"Debug"는 여기서 리다이렉트 됩니다.그 외의 용도는, 「디버깅」(명료화)를 참조해 주세요.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

컴퓨터 프로그래밍 및 소프트웨어 개발에서 디버깅은 컴퓨터 프로그램, 소프트웨어 또는 시스템 내의 버그(정확한 동작을 방해하는 결함 또는 문제)를 찾아 해결하는 프로세스입니다.

디버깅 방법에는 대화형 디버깅, 제어 흐름 분석, 유닛 테스트, 통합 테스트, 로그 파일 분석, 애플리케이션 또는 시스템레벨에서의 감시, 메모리 덤프, 프로파일링이 포함됩니다.많은 프로그래밍 언어 및 소프트웨어 개발 툴은 디버깅에 도움이 되는 디버깅 프로그램도 제공합니다.

어원학

Mark II의 컴퓨터 로그 엔트리로 페이지에 나방이 붙어 있습니다.

"버그"[1]와 "디버깅"이라는 용어는 1940년대에 그레이스 호퍼 제독에 의해 널리 사용되었다.그녀가 하버드 대학에서 Mark II 컴퓨터로 작업하고 있을 때, 그녀의 동료들은 릴레이에 걸려 작동을 방해하는 나방을 발견했고, 이에 대해 그녀는 그들이 시스템을 "디버깅"하고 있다고 말했다.그러나 "기술적 오류"라는 의미에서 "버그"라는 용어는 적어도 1878년과 토마스 에디슨으로 거슬러 올라간다(자세한 내용은 소프트웨어 버그 참조).비슷하게, "디버깅"이라는 용어는 컴퓨터의 세계로 들어가기 전에 항공학에서 용어로 사용되었던 것으로 보인다.사실, 그레이스 호퍼는 인터뷰에서 자신이 [citation needed]그 용어를 조작하고 있지 않다고 말했다.나방은 기존 용어와 일치하여 저장되었습니다.1944년 [2]10월 27일, J. 로버트 오펜하이머(뉴멕시코 로스앨러모스의 제2차 세계 대전 원폭 맨해튼 프로젝트 책임자)가 UC 버클리 대학의 어니스트 로렌스 박사에게 보낸 편지에서 추가적인 기술 직원 채용에 관한 이 용어를 사용했다.

옥스포드 영어사전 '디버깅'은 1945년 영국 왕립항공학회지에 실린 기사에서 비행기 엔진 테스트에 사용된 '디버깅'이라는 용어를 인용하고 있다."공군"(1945년 6월 페이지 50)의 기사에서도 항공기 카메라의 디버깅에 대해 언급하고 있다.호퍼의 벌레는 1947년 9월 9일에 발견되었다.컴퓨터 프로그래머들은 1950년대 초반까지 이 용어를 채택하지 않았다.1951년에 Gill이 쓴[3] 중요한 기사는 프로그래밍 오류에 대한 가장 초기의 심층적인 논의이지만, "버그" 또는 "디버깅"이라는 용어는 사용하지 않는다.ACM의 디지털 라이브러리에서 "디버깅"이라는 용어는 1952년 ACM National [4][5][6]Meetings에서 세 개의 논문에 처음 사용되었습니다.세 명 중 두 명은 따옴표 안에 그 용어를 사용한다.1963년까지 "디버깅"은 CTSS [7]매뉴얼 1페이지에서 설명 없이 언급되는 일반적인 용어였습니다.

페기 A. 키드웰의 기사 Stocking the Capture Computer[8] Bug는 "버그"와 "디버그"의 어원에 대해 더 자세히 설명합니다.

범위

소프트웨어와 전자 시스템이 일반적으로 복잡해짐에 따라 다양한 일반적인 디버깅 기법이 이상 징후를 검출하고 영향을 평가하며 시스템에 대한 소프트웨어 패치 또는 전체 업데이트를 스케줄링하는 더 많은 방법으로 확장되었습니다."이상"과 "불일관성"이라는 단어는 보다 중립적인 용어로 사용될 수 있으며, "오류"와 "결함" 또는 "버그"라는 단어를 피할 수 있습니다. 이 단어에서는 소위 말하는 모든 오류, 결함 또는 버그를 반드시 수정해야 합니다(어떤 대가를 치르더라도).대신 이상(또는 불일치)을 제거하기 위한 변경이 시스템에 비용 효율이 높은지 또는 예정된 새 릴리스로 인해 변경이 불필요해지는지를 판단하기 위해 영향 평가를 수행할 수 있습니다.시스템의 안전이나 미션 크리티컬한 문제가 모두 있는 것은 아닙니다.또, 기존의 문제를 안고 사는 것(「병보다 치료법이 더 나빠지는」)보다, 장기적으로, 유저에게 있어서, 변화가 더 불쾌하게 하는 상황을 피하는 것이 중요합니다.일부 변칙의 수용가능성에 대한 기본적인 결정은 사람들이 문제의 존재를 부정하고 결점이 없는 것으로 나타나도록 유혹을 받을 수 있는 "결점 없는" 위임 문화를 피할 수 있다.비용 대 편익 영향 평가와 같은 부수적인 문제를 고려하여, 이상 발생 빈도(같은 "버그"가 발생하는 빈도)를 결정하도록 광범위한 디버깅 기법이 확장되어 시스템 전체에 미치는 영향을 평가할 수 있게 됩니다.

도구들

다음 항목도 참조하십시오.디버거
비디오 게임 콘솔에서의 디버깅은 보통 개발자를 위한 이 Xbox 디버깅 유닛과 같은 특수 하드웨어로 이루어집니다.

디버깅은 단순한 오류 수정부터 데이터 수집, 분석 및 업데이트 스케줄링과 같은 길고 귀찮은 작업까지 복잡합니다.프로그래머의 디버깅 스킬은 문제를 디버깅할 수 있는 주요 요인이 될 수 있지만 소프트웨어 디버깅의 어려움은 시스템의 복잡성에 따라 크게 달라지며 사용하는 프로그래밍 언어 및 디버깅 등의 사용 가능한 도구에 따라 어느 정도 달라집니다.디버거는 프로그래머가 프로그램 실행을 감시, 중지, 재시작, 중단점 설정 및 메모리 값 변경을 가능하게 하는 소프트웨어 도구입니다.디버거라는 용어는 디버깅을 수행하는 사람을 가리킬 수도 있습니다.

일반적으로 Java와 같은 고급 프로그래밍 언어는 예외 처리 및 유형 검사와 같은 기능이 있기 때문에 디버깅을 쉽게 합니다. 이는 불규칙한 동작의 실제 원인을 찾기 쉽게 하기 때문입니다.C나 어셈블리등의 프로그래밍 언어에서는, 버그로 인해 메모리 파손등의 사일런트 문제가 발생하는 일이 있습니다.또, 최초의 문제가 발생한 장소를 특정하는 것은 어려운 경우가 많습니다.이 경우 메모리 디버거 도구가 필요할 수 있습니다.

특정 상황에서는 특정 언어에 고유한 범용 소프트웨어 도구가 매우 유용할 수 있습니다.이들은 정적 코드 분석 도구의 형태를 취합니다.이러한 툴은 컴파일러나 인터프리터처럼 구문보다는 의미론(예를 들어 데이터 흐름)에 더 초점을 맞추는 소스 코드 내에서 공통적이고 드문 알려진 문제 세트를 찾습니다.

상용 툴과 무료 툴이 모두 다양한 언어를 지원하며, 일부는 수백 가지 다른 문제를 탐지할 수 있다고 주장합니다.이러한 도구는 코드 워크스루를 수행하는 것이 비현실적인 매우 큰 소스 트리를 확인할 때 매우 유용합니다.검출된 문제의 일반적인 예로는 변수에 값을 할당하기 전에 발생하는 변수 참조를 들 수 있습니다.다른 예로, 이러한 도구 중 일부는 언어가 필요하지 않을 때 강력한 유형 검사를 수행합니다.따라서 구문적으로 올바른 코드에서 발생할 수 있는 오류를 더 잘 찾을 수 있습니다.그러나 이러한 툴은 false positive로 평판이 나 있어 올바른 코드가 의심스러운 것으로 플래그가 붙어 있습니다.오래된 Unix lint 프로그램은 초기 예시입니다.

전자 하드웨어(예: 컴퓨터 하드웨어) 및 저수준 소프트웨어(예: BIOS, 장치 드라이버) 및 펌웨어 디버깅에는 오실로스코프, 논리 분석기 또는 ICE(In-Circuit Emulator)와 같은 계측기가 단독으로 또는 조합되어 사용되는 경우가 많습니다.ICE는 저수준의 소프트웨어와 펌웨어에서 일반적인 소프트웨어 디버거의 많은 작업을 수행할 수 있습니다.

디버깅 프로세스

보통 디버깅의 첫 번째 단계는 문제를 재현하는 것입니다.이는 병렬 프로세스 및 일부 Heisenbugs와 같은 사소한 작업이 될 수 있습니다.또, 특정의 유저 환경이나 사용 이력으로 인해, 문제를 재현하기 어려운 경우가 있습니다.

버그가 재현된 후에는 프로그램 입력을 간소화하여 디버깅을 용이하게 해야 할 수 있습니다.예를 들어 컴파일러의 버그로 인해 큰 소스 파일을 해석할 때 오류가 발생할 수 있습니다.다만, 테스트 케이스를 심플화하면, 원래의 소스 파일의 몇 행만이 같은 크래시를 재현할 수 있습니다.이러한 단순화는 분할 및 정복 방식을 사용하여 수동으로 수행할 수 있습니다.프로그래머는 원래의 테스트 케이스의 일부를 제거하고 문제가 아직 존재하는지 확인합니다.GUI에서 문제를 디버깅할 때 프로그래머는 원래 문제 설명에서 일부 사용자 상호 작용을 건너뛰고 나머지 작업이 버그가 나타나기에 충분한지 여부를 확인할 수 있습니다.

테스트 케이스가 충분히 단순화되면 프로그래머는 디버거 도구를 사용하여 프로그램 상태(변수 값 및 콜 스택)를 검사하고 문제의 발생원을 추적할 수 있습니다.또는 트레이스를 사용할 수도 있습니다.단순한 경우 트레이스는 프로그램 실행 [citation needed]시 특정 시점에서 변수 값을 출력하는 인쇄문 몇 개에 불과합니다.

기술

  • 대화형 디버깅은 응용 프로그램의 코드 실행을 한 번에 한 단계씩 처리하고 응용 프로그램 상태를 검사하거나 변경하기 위해 일시 중지할 수 있는 디버거 도구를 사용합니다.이러한 도구는 일반적으로 특정 변수가 변경될 때까지 실행할 수 있는 워치포인트와 예외나 공유 라이브러리의 로딩과 같은 특정 종류의 프로그램 이벤트에 대해 디버거를 중지시키는 캐치포인트를 지원합니다.
  • 인쇄 디버깅 또는 트레이스는 프로세스의 실행 흐름과 데이터 진행 상황을 나타내는 트레이스 스테이트먼트(라이브 또는 녹음된)를 감시하는 행위입니다.트레이스는 특별한 도구(GDB의 트레이스 등)를 사용하거나 트레이스 문을 소스 코드에 삽입하여 실행할 수 있습니다.후자는 C에서 printf 함수를 사용하기 때문에 printf 디버깅이라고도 합니다.이러한 종류의 디버깅은 초보 지향 BASIC 프로그래밍 언어의 원래 버전에서 TRON 명령에 의해 활성화되었습니다.TRON은 "Trace On"을 의미합니다.TRON은 프로그램 실행 시 각 BASIC 명령줄의 라인 번호를 인쇄합니다.
  • 원격 디버깅은 디버거와 다른 시스템에서 실행되는 프로그램을 디버깅하는 프로세스입니다.원격 디버깅을 시작하기 위해 디버거는 로컬 영역 네트워크 등의 통신 링크를 통해 원격 시스템에 연결합니다.그런 다음 디버거는 원격 시스템에서 프로그램 실행을 제어하고 해당 상태에 대한 정보를 검색할 수 있습니다.
  • 사후 디버깅은 프로그램이 이미 크래시된 후 디버깅하는 것입니다.관련 기술에는 로그 파일 검사, [9]크래시 콜스택 출력, 크래시 프로세스의 메모리 덤프(또는 코어 덤프) 분석 등 다양한 트레이스 기술이 포함됩니다.프로세스의 덤프는 시스템에 의해 자동으로 취득할 수 있습니다(예를 들어 처리되지 않은 예외로 인해 프로세스가 종료된 경우).또는 프로그래머가 삽입한 명령으로 취득하거나 대화형 사용자가 수동으로 취득할 수 있습니다.
  • "늑장 울타리" 알고리즘: Edward Gauss는 1982년 "Communications of the ACM" 기사에서 이 단순하지만 매우 유용하고 지금은 유명한 알고리즘을 다음과 같이 묘사했습니다: "Alaska에 늑대가 한 마리 있는데 어떻게 찾으세요?먼저 주 한가운데 울타리를 치고 늑대가 울부짖을 때까지 기다렸다가 울타리의 어느 쪽에 있는지 판단해.늑대가 [10]보일 때까지 저쪽에서만 과정을 반복하세요.이것은 예를 들어 Git 버전 제어 시스템에서 명령어 git bisect로 구현되며, 이 명령어는 위의 알고리즘을 사용하여 어떤 커밋이 특정 버그를 발생시켰는지 판단합니다.
  • 기록 및 재생 디버깅은 프로그램 실행 기록을 만드는 기술입니다(예를 들어 Mozilla의 무료 rr 디버깅 도구를 사용하여 역방향 디버깅/실행을 활성화합니다). 이 기술은 재생 및 대화식으로 디버깅할 수 있습니다.간헐적, 비결정적 및 기타 재현하기 어려운 장애의 원격 디버깅 및 디버깅에 도움이 됩니다.
  • 시간 여행 디버깅은 소스 코드를 통해 시간을 되돌리는 과정(예를 들어 Undo Live Recorder 사용)으로, 컴퓨터 프로그램 실행 중에 무슨 일이 일어나는지 이해하고, 사용자가 프로그램과 상호작용할 수 있도록 하며, 필요에 따라 이력을 변경하고, 프로그램이 어떻게 반응하는지 관찰합니다.
  • Delta Debugging – 테스트 케이스의 심플화를 [11]: p.123 자동화하는 기술.
  • Saff Squeeze – 불합격 테스트 [12][13]부분의 점진적 인라이닝을 사용하여 테스트 내에서 불합격 부분을 분리하는 기술.
  • 인과관계 추적:계산에서 [14]원인 영향 사슬을 추적하는 기법이 있다.이러한 기술은 null 포인터 참조와 [15][16]같은 특정 버그에 맞게 조정할 수 있습니다.

임베디드 시스템 디버깅

범용 컴퓨터 소프트웨어 설계 환경과 달리 임베디드 환경의 주요 특징은 개발자가 사용할 수 있는 플랫폼(CPU 아키텍처, 벤더, 운영 체제 및 그 변형)의 수입니다.임베디드 시스템은 정의상 범용 설계가 아닙니다.일반적으로 단일 태스크(또는 소규모 태스크)용으로 개발되며 플랫폼은 해당 애플리케이션을 최적화하기 위해 특별히 선택됩니다.이러한 사실은 임베디드 시스템 개발자의 삶을 어렵게 할 뿐만 아니라 플랫폼마다 다른 디버깅 도구가 필요하기 때문에 이러한 시스템의 디버깅과 테스트도 어렵게 만듭니다.

위에서 언급한 이질성의 문제에도 불구하고, 일부 디버거는 연구 프로토타입뿐만 아니라 상업적으로 개발되었습니다.상용 솔루션의 예로는 Green Hills [17]Software, Lauterbach GmbH[18] 및 Microchip의 MPLAB-ICD(회로 내 디버거용)가 있습니다.연구용 프로토타입 툴의 두 가지 예는 Avexha와[19] Flocklab입니다.[20]모두 저비용 임베디드 프로세서에서 사용 가능한 기능인 On-Chip Debug Module(OCDM; 온칩디버깅 모듈)을 활용합니다.이 모듈에서는 신호가 표준 JTAG 인터페이스를 통해 노출됩니다.이들은 애플리케이션 변경이 얼마나 필요한지 및 이들이 대응할 수 있는 이벤트 비율을 기준으로 벤치마킹됩니다.

임베디드 시스템의 디버깅은 시스템의 버그를 특정하는 일반적인 태스크와 더불어 시스템의 동작 상태에 대한 정보를 수집하여 시스템의 성능을 향상시키거나 기타 중요한 특성(에너지 소비, 신뢰성, 실시간 해상도 등)을 최적화하는 방법을 모색합니다.폰스 등)

안티 디버깅

안티 디버깅은 "대상 프로세스를 역엔지니어링 또는 디버깅하려는 시도를 방해하는 컴퓨터 코드 내의 하나 이상의 기술을 구현하는 것"[21]입니다.인식된 게시자가 복사 방지 스키마에서 적극적으로 사용하지만 탐지 및 [22]제거를 복잡하게 하기 위해 멀웨어에서도 사용됩니다.안티 디버깅에는 다음과 같은 기술이 사용됩니다.

  • API 기반: 시스템 정보를 사용하여 디버거가 있는지 확인합니다.
  • Exception-based: 예외에 간섭이 있는지 확인합니다.
  • 프로세스 및 스레드 블록: 프로세스 및 스레드 블록이 조작되었는지 확인합니다.
  • 수정된 코드: 소프트웨어 중단점을 처리하는 디버거에 의해 변경된 코드가 있는지 확인합니다.
  • 하드웨어 기반 및 레지스터 기반: 하드웨어 중단점 및 CPU 레지스터 확인
  • 타이밍 및 지연: 명령 실행에 걸린 시간을 확인합니다.
  • 디버거 탐지 및 패널티 적용[22]

디버거가 검출되면 "악의 나무는 쓴 열매를 맺는다.프로그램 디스크를 파기하고 있습니다."라는 메시지가 표시된 후 플로피 디스크 드라이브에서 경고음이 울리고 사용자가 [23][24]다시 시도하지 못하도록 위협합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "InfoWorld Oct 5, 1981". 5 October 1981. Archived from the original on September 18, 2019. Retrieved July 17, 2019.
  2. ^ "Archived copy". Archived from the original on 2019-11-21. Retrieved 2019-12-17.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  3. ^ S. Gill, Wayback Machine, Proceedings of the Royal Society of London에 보관된 EDSAC의 프로그램 오류 진단 2020-03-06.시리즈 A, 수리 및 물리과학, 제206권, 제1087호(1951년 5월 22일), 538-554페이지
  4. ^ Robert V. D. Campbell, Wayback Machine에서의 자동 계산의 진화, 2019-09-18, 1952년 ACM 전국 회의(Pittsburgh), 페이지 29-32, 1952년.
  5. ^ Alex Orden, 디지털 컴퓨터의 선형 불평등 시스템의 해결, 1952년 ACM 전국회의(Pittsburgh), 페이지 91-95, 1952년.
  6. ^ 하워드 B.데무스, 존 B.잭슨, 에드먼드 클라인, 노스 메트로폴리스, 월터 오베달, 제임스 H. 리처드슨, MANIAC doi=10.1145/800259.808982, 1952년 ACM 전국회의(토론토), 13-16페이지
  7. ^ The Compatible Time-Sharing System 2012-05-27 Wayback Machine, M.I.T. Press, 1963년
  8. ^ Peggy Aldrich Kidwell, Stocking the Scapting Computer Bug, IEEE Annals of Computing, 1998.
  9. ^ "Postmortem Debugging". Archived from the original on 2019-12-17. Retrieved 2019-12-17.
  10. ^ E. J. Gauss (1982). "Pracniques: The 'Wolf Fence' Algorithm for Debugging". Communications of the ACM. 25 (11): 780. doi:10.1145/358690.358695. S2CID 672811.
  11. ^ Zeller, Andreas (2005). Why Programs Fail: A Guide to Systematic Debugging. Morgan Kaufmann. ISBN 1-55860-866-4.
  12. ^ "Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze". Archived from the original on 2012-03-11.
  13. ^ Rainsberger, J.B. "The Saff Squeeze". The Code Whisperer. Retrieved 28 March 2022.
  14. ^ Zeller, Andreas (2002-11-01). "Isolating cause-effect chains from computer programs". ACM SIGSOFT Software Engineering Notes. 27 (6): 1–10. doi:10.1145/605466.605468. ISSN 0163-5948. S2CID 12098165.
  15. ^ Bond, Michael D.; Nethercote, Nicholas; Kent, Stephen W.; Guyer, Samuel Z.; McKinley, Kathryn S. (2007). "Tracking bad apples". Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07. p. 405. doi:10.1145/1297027.1297057. ISBN 9781595937865. S2CID 2832749.
  16. ^ Cornu, Benoit; Barr, Earl T.; Seinturier, Lionel; Monperrus, Martin (2016). "Casper: Automatic tracking of null dereferences to inception with causality traces". Journal of Systems and Software. 122: 52–62. arXiv:1502.02004. doi:10.1016/j.jss.2016.08.062. ISSN 0164-1212. S2CID 28161871. Archived from the original on 2022-01-25. Retrieved 2019-06-23.
  17. ^ "SuperTrace Probe hardware debugger". www.ghs.com. Archived from the original on 2017-12-01. Retrieved 2017-11-25.
  18. ^ "Debugger and real-time trace tools". www.lauterbach.com. Archived from the original on 2022-01-25. Retrieved 2020-06-05.
  19. ^ Tancreti, Matthew; Hossain, Mohammad Sajjad; Bagchi, Saurabh; Raghunathan, Vijay (2011). "Aveksha: A Hardware-software Approach for Non-intrusive Tracing and Profiling of Wireless Embedded Systems". Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems. SenSys '11. New York, NY, USA: ACM: 288–301. doi:10.1145/2070942.2070972. ISBN 9781450307185. S2CID 14769602.
  20. ^ Lim, Roman; Ferrari, Federico; Zimmerling, Marco; Walser, Christoph; Sommer, Philipp; Beutel, Jan (2013). "FlockLab: A Testbed for Distributed, Synchronized Tracing and Profiling of Wireless Embedded Systems". Proceedings of the 12th International Conference on Information Processing in Sensor Networks. IPSN '13. New York, NY, USA: ACM: 153–166. doi:10.1145/2461381.2461402. ISBN 9781450319591. S2CID 447045.
  21. ^ Shields, Tyler (2008-12-02). "Anti-Debugging Series – Part I". Veracode. Archived from the original on 2016-10-19. Retrieved 2009-03-17.
  22. ^ a b "Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh" (PDF). Archived from the original (PDF) on 2011-10-01. Retrieved 2010-10-25.
  23. ^ Ross J. Anderson (2001-03-23). Security Engineering. p. 684. ISBN 0-471-38922-6.
  24. ^ "Microsoft Word for DOS 1.15". Archived from the original on 2013-05-14. Retrieved 2013-06-22.

추가 정보

외부 링크

Wiki 인용문에는 디버깅과 관련된 인용문이 있습니다.
Wikibook 컴퓨터 프로그래밍 원칙에는 다음 항목에 대한 페이지가 있습니다.