이맥스 멈춤 현상 해결로 알아보는 디버깅 기술

이맥스에서 컴파일(M-x compile)이나 검색(M-x rgrep)을 하면 결과를 다른 버퍼(예를 들면, 컴파일 출력은 *compilation* 버퍼)에서 표시한다. 단순히 보여주기만 하는 것이 아니라 오류나 검색 위치로 바로 가기도 지원한다. 오류(또는 검색) 출력 위에 커서를 이동하고 엔터를 누르면 다른 윈도우에 커서가 가르키는 파일을 열고 해당 위치로 이동한다.

---

문제 없이 잘 동작하는 바로 가기 기능이 갑자기 수 분 동안 멈추는 현상이 발생했다. 이를 해결하지 못하면 개발 생산성에 급격한 저하가 발생할 수 밖에 없다. 따라서 무조껀 이것을 해결하고. 본연의 업무 중 하나인. 개발 업무를 진행해야 했다.

---

얼마간 멈추고 CPU를 과도하게 사용하는 상황이라면 CPU 프로파일링(profiling)으로 접근해보는게 좋다. 이맥스 리스프는 M-x profiler-start로 프로파일링을 시작한다. 문제를 재현한 후 M-x profiler-report로 프로파일러의 결과를 확인한다. 아래는 이번 문제의 프로파일링 결과이고 여기에서 문제의 함수 (projectile-project-files)를 찾았다.

77,298,897,270  98% - command-execute
77,298,897,270  98%  - call-interactively
77,298,897,270  98%   - funcall-interactively
77,289,270,551  98%    - compile-goto-error
77,289,268,151  98%     - next-error-internal
77,289,265,768  98%      - compilation-next-error-function
77,289,202,791  98%       - apply
77,289,202,791  98%        - compilation-find-file
77,289,202,791  98%         - apply
77,289,202,791  98%          - compilation-find-file-projecti...
77,107,976,619  98%           - projectile-current-project-dirs
77,107,976,028  98%            - projectile-project-dirs
75,832,952,793  96%             - projectile-project-files

---

프로파일링으로 문제 함수를 찾았으니 함수 디버깅으로 원인을 조사했다. 조사 결과는 함수에 전달되는 인자값 project-root가 예상과 다랐다. 이 매개변수에는 작업 중인 프로젝트의 디렉토리 경로(예를 들면, /Users/ian/workspace/ffmpeg)가 들어가야 하는데, 엉뚱하게도 홈디렉토리 경로(내 경우는, /Users/ian)를 값으로 전달했다.

 

(projectile-project-files 함수)

(defun projectile-project-files (project-root)
  "Return a list of files for the PROJECT-ROOT."
  (let (files)
    ;; ...
    ))

---

이 함수는 프로젝트내 포함된 파일의 목록(*)을 반환한다. 정상적이었다면, 즉, 프로젝트의 디렉토리를 받았다면, 그리 오래 걸리지 않을 -길어야 몇 초 이내- 작업이다. 그런데, 홈디렉토리라면 사정이 달라진다. 엄청나게 많은 파일이 존재하기 때문이다. 홈 디렉토리에 존재하는 방대한 파일을 순회하려면 수 분의 시간이 필요하다.

(*) 파일 목록을 캐싱하기 때문에 동일 프로젝트에 대해서 두번째로 호출할 경우 매우 빠르게 응답한다.

---

이제 매개변수의 값-홈 디렉토리 경로-가 문제의 원인임을 알았다. 이 매개션수가 어디에서 왔는지 찾으면 된다. 상위 함수로 이동하면서 문제의 인자값 생성하는 코드를 찾았다. 콜스택 바로 아래에서 인자의 값을 생성하는 코드를 찾았다. 이 함수는 (projectile-project-files) 이고, 아래의 함수 정의에서 보듯이 (projectile-acquire-root)가 프로텍트 루트를 찾아낸다. 

 

(projectile-current-project-files 함수)

(defun projectile-current-project-files ()
  "Return a list of the files in the current project."
  (projectile-project-files (projectile-acquire-root)))

---

문제의 인자값을 생성하는 함수 (projectile-acquire-root)의 디버깅해보자. (projectile-acquire-root)부터 살펴보고, 이 함수가 호출하는 (projectile-project-root)로, 다시 이것은 사용하는 (projectile-root-bottom-up) 함수로 파고 들었다. 마침내, 이 함수에서 문제의 원인을 찾았다..

이 (projectile-root-bottom-up) 함수는 프로젝트 최상의 디렉토리에 존재할 만한 몇가지 종류의 파일(예를 들면, .git과 같은 버전 관리 시스템의 파일이나 명시적인 .projectile 파일)이 있으면 그 위치를 프로젝트 루트 디렉토리로 간주한다. 디버깅 결과로는 홈디렉토리에 .projectile이 존재하여 이 위치를 프로젝트 루트라고 판단하는 실행 흐름을 확인했다.

홈디렉토리에 존재하는 .projectile 파일을 삭제하여 문제를 해결했다. 실수로 홈디레토리에 만들었거나 다른 곳에 있는 있던 것이 옮겨진 듯 하다.

---

위에 구체적인 문제 해결 사례를 일반화하면 다음과 같다.

• 얼마간 멈추는 현상이 발생한다면, CPU 프로파일링으로 문제의 실마리를 찾을 수 있다.
• 완전히 멈춘다면, 무한 루프이거나 교착 상태일 수 있다. 프로세스 상태를 관찰하면 어떤 종류의 것인지 추측 가능하다. (자세한 내용은 교착상태(deadlock)를 프로세스 상태와 디버거를 사용해서 찾아내기에서 확인할 수 있다.)
• 문제의 실마리를 찾았다면 절반은 해결한 셈이다. 그 지점부터 디버깅하면서 원인을 찾아본다.