Debugger

디버거 상태 추적

breakpoint, watch, call stack은 각각 다른 질문에 답한다. 어디서 값이 틀어졌는지 찾으려면 실행을 멈추는 위치와 관찰할 상태를 좁혀야 한다.

01

재현 입력 고정

같은 인자, 같은 파일, 같은 환경에서 다시 깨지는 최소 시나리오를 만든다.

02

경계를 이분한다

정상 상태가 마지막으로 확인되는 지점과 처음 깨지는 지점 사이를 좁힌다.

03

상태 기록

변수 값, 스레드, call stack을 함께 남겨 원인을 가정이 아니라 증거로 바꾼다.

step over
현재 함수 안에서 다음 줄 호출 내부로 들어가지 않고 흐름만 확인한다.
큰 라이브러리 호출은 건너뛴다.
step into
호출 내부 진입 내 코드 함수가 값을 바꾸는지 확인할 때 사용한다.
템플릿 코드는 깊게 들어갈 수 있다.
watchpoint
값 변경 시 정지 특정 메모리 위치가 언제 바뀌는지 잡는다.
지원과 비용은 디버거마다 다르다.
thread view
동시성 관찰 어느 스레드가 lock을 잡고 어디서 멈췄는지 본다.
deadlock 분석에 필요하다.

최적화 옵션 · 조건부 중단 · 스레드 점검

최적화 옵션 릴리스 최적화 때문에 변수와 흐름이 디버거에서 다르게 보이지 않는가.
조건부 중단 수천 번 반복되는 루프에서 문제 입력일 때만 멈추도록 조건을 걸었는가.
스레드 동시성 버그에서 현재 스레드만 보고 다른 스레드의 상태를 놓치지 않는가.

조사 메모

// 1. 실패 입력을 고정한다.
// 2. 정상/오류 경계를 breakpoint로 좁힌다.
// 3. watchpoint로 값이 처음 바뀌는 지점을 찾는다.
// 4. call stack과 thread id를 함께 기록한다.