PID가 가리키는 대상을 다시 확인하기
프로세스에 연결할 때는 작업 관리자에서 본 숫자를 입력하면 된다고 생각하기 쉽습니다. 하지만 프로그램이 종료되고 다시 시작됐다면 PID가 바뀔 수 있고 이전 번호가 다른 프로세스에 재사용될 수도 있습니다. 이름이 같은 프로세스가 여러 개 실행되는 경우에는 경로와 시작 시각도 함께 확인하는 편이 좋습니다. 연결 직전에 대상이 살아 있는지, 조사하려는 실행 인스턴스가 맞는지 다시 확인하세요. 디버거가 연결을 거절했다는 메시지만으로 관리자 권한이 필요하다고 단정하면 다른 문제를 놓칠 수 있습니다. 대상 식별은 연결 권한보다 먼저 확인할 조건입니다.
같은 운영체제와 아키텍처인지 보기
Windows 프로그램을 조사하려면 네이티브 Windows 디버깅을 지원하는 GDB가 필요합니다. Windows에서 브라우저를 열었다고 WSL 내부의 Linux용 GDB가 자동으로 일반 Windows 프로세스에 붙는 것은 아닙니다. 디버거가 실제 어느 환경에서 실행되는지와 대상이 어디에 있는지를 구분하세요. 또한 대상의 아키텍처를 지원하는 빌드인지도 확인해야 합니다. 32비트와 64비트 환경의 조합은 도구 지원 범위에 영향을 줍니다. DBG Desk에 지정한 gdb.exe의 절대 경로를 확인하면 PATH에 있는 다른 GDB를 실수로 실행한 상황을 줄일 수 있습니다.
권한이나 보호 설정의 거부는 그대로 구분하기
PID와 도구 조합이 맞아도 운영체제 권한이나 대상의 보호 정책 때문에 연결이 거절될 수 있습니다. 다른 계정으로 실행된 프로세스나 보호된 시스템 구성요소는 일반 사용자 프로그램과 조건이 다릅니다. 이때 오류를 숨기거나 무작정 보안 설정을 끄는 방식으로 접근하지 말고 GDB가 돌려준 원문과 대상의 실행 조건을 기록하세요. 조사 권한이 있는 자신의 개발 프로그램을 같은 사용자 계정에서 실행해 기본 연결이 되는지 먼저 확인할 수 있습니다. 작은 예제에서도 실패하는지 특정 대상에서만 실패하는지를 구분하면 환경 문제와 대상의 제한을 분리하는 데 도움이 됩니다.
연결 후에는 정지와 분리의 의미 확인하기
Attach는 이미 실행 중인 프로그램에 디버거를 연결하는 작업이며 새 프로그램을 시작하는 것과 다릅니다. 연결 뒤에는 현재 멈춘 위치가 main일 필요가 없습니다. 프로그램이 하던 작업의 중간에서 멈췄다면 호출 스택을 보고 현재 문맥부터 이해해야 합니다. 서비스를 오래 정지하면 외부의 시간 제한이나 연결 상태에도 영향이 생길 수 있습니다. 조사 후 Detach하면 일반적으로 디버거를 분리하고 대상이 실행을 이어가게 합니다. 반면 디버거 프로세스를 강제로 종료했을 때 대상이 어떻게 되는지는 플랫폼과 상태에 영향을 받습니다. 종료 전에 명시적으로 연결을 정리하세요.
작은 대상으로 연결 경로 확인하기
Attach가 실패하면 같은 사용자 계정에서 만든 대기용 개발 프로그램으로 연결 절차를 확인해 보세요. 작은 대상에는 연결되는데 원래 대상만 거절한다면 브라우저 인증이나 서버 연결 문제와는 구분할 수 있습니다. 반대로 모든 PID에서 실패하면 지정한 GDB의 종류와 실행 환경을 우선 점검합니다. 오류 메시지를 기록할 때는 실제 프로세스 이름과 경로를 공개해도 되는지도 확인하세요. 연결 실패를 재현하는 동안 프로그램을 여러 번 재시작했다면 매번 최신 PID를 다시 가져와야 합니다. 재사용된 숫자를 계속 시도하면 서로 다른 대상의 결과를 하나의 문제처럼 비교하게 됩니다.