728x90
Yuan, D., Mai, H., Xiong, W., Tan, L., Zhou, Y., and Pasupathy, S. 2010. SherLog: error diagnosis by connecting clues from run-time logs. SIGPLAN Not. 45, 3 (Mar. 2010), 143-154.
컴퓨터 시스템은 소프트웨어 버그나 관리자의 configuration 실수 등으로 인해서 종종 에러가 발생한다. 이러한 에러 현상을 분석하고 진단하기 위해서 동일한 에러를 재현하는 것이 필요한데 다음과 같은 이유 등으로 이런 작업들이 매우 어렵다.
1. privacy로 인한 사용자의 입력값과 파일의 내용의 접근이 어렵고
2. 동일한 실행 환경을 구축하기 힘들고
3. 멀티프로세서와 같은 환경에서 실행이 deterministic 하지 못하기 때문에 어렵다.
이러한 이유로 대부분의 업체들은 사용자로부터 에러 로그를 받아서 소스 코드와 비교해가면서 문제를 찾아내는데 사실 이러한 작업은 매우 번거로우며 시간이 많이 소요되는 일이다. 그래서 저자들은 Sherlog (아마도 셜록홈즈에서 음을 차용한듯)이라는 진단 툴을 개발하였다.
SherLog의 특징은 사용자가 보내준 에러 메세지 로그와 소스 코드만 가지고 에러의 원인을 분석, 진단할뿐 다른 논문들 처럼 에러를 재현하려고 하지 않는다. 로그의 분석을 위해서 Log Parser를 가지고 있으며 Log가 매우 다양한 포맷으로 생성되기 때문에 Log Parser를 생성해주는 Log Parser Generation 도구도 만들었다. Log Parser가 하는 일은 소스에서 로그 출력부분을 찾고 실제 에러 메세지 로그와 비교(RegEx을 이용)하여 로그와 소스를 매칭한다.
그런 다음 가능성있는 로그 출력부분의 조합을 만들어 Path를 만들게 되는데 단순 조합은 무수히 많이 생길 수 있어서 이 중에서 실제 실행가능한 Path를 찾기 위해 if-else나 변수의 값에 따라 결정되어지는 control flow를 분석하여 Must-Path, May-Path, Pruned-Path로 구분한다. Must-Path는 반드시 수행되는 Path, May-Path는 가능성 있는 예를들면 if에서 조건에 따라 A나 B Path로 수행되는 경우를 말하며 Pruned-Path는 로그가 이 Path로는 에러 메세지 로그 형태로 만들어 질 수 없는 경우를 말한다.
이렇게 3종류로 분석이 되면 분석 결과를 출력해주는데 Must-Path가 있다면 Must-Path들(하나 이상이 생길 수 있다)을 분석하면 에러의 발생 원인을 진단할 수 있다. 만약 May-Path만 있다면 가능한 경우가 여러가지여서 좀 더 분석에 시간이 걸리게 된다.
논문을 보면 rmdir 명령을 예로들어 설명하고 있는데 이 부분만 간단히 살펴봐도 어떻게 진단하는 것인지 쉽게 알 수 있다. 단, 모든 실제 어플리케이션이 가능한 것은 아니라고 하고 apache와 같은 서버 프로그램들도 테스트를 했는데 길게는 40분 정도 진단 시간이 소요된다고 한다.
rmdir 분석 결과를 첨부한다.
728x90