[DevLog][PintOS] PRJ2 User Program/Out of Memory Test

Memory Leak in C

핀토스의 Project2에는 OOM 테스트가 있는데, 할당 가능한 자원을 모두 소진할 때까지 프로세스를 fork하는 무시무시한 테스트이다. 프로세스를 생성하고 종료시키는 과정을 10회 반복하므로서 fork 가능한 프로세스의 수가 매번 같은지, 즉 종료 과정에서 메모리 누수가 발생하지 않는지 체크한다. 운영체제와 시스템 콜의 요구사항에 대해 알고, 구현하면 pass되었던 테스트와는 달리, 이 테스트는 실제로 코드가 안전하게 (누수 없이) 짜여져 있는지를 확인하기 때문에 무엇보다도 논리적으로.. 코드를 잘 짜는 역량이 중요했던 것 같다.

1) 메모리 할당 함수를 쓰면, 잘 해제해 주자.

tid_t thread_create(...) {
  struct thread_child *child;
  struct thread *t;
  tid_t tid;

  ASSERT(function != NULL);

  /* Allocate thread. */
  t = palloc_get_page(PAL_ZERO);
  if (t == NULL) return TID_ERROR;

  ...

  /* Add to parent's child list. */
  child = calloc(1, sizeof(struct thread_child));
  if (child == NULL) {
    palloc_free_page(t); // 🔥 여기
    return TID_ERROR;
  }
  ...

당연한 말이지만, 애초에 이 부분을 신경쓰면서 코드를 짜지 않으면 누수 지점을 찾기 어려워지는 경우가 많았다. 18번 라인에서 palloc_free_page(t)를 해주지 않으면 메모리 누수가 발생한다. 오류가 발생했을 때 예외 처리를 하면서 이전에 할당받았던 메모리를 잘 해제해 주어야 한다. 함수가 리턴하는 모든 케이스에서 해제해 주는 것을 잊지 말자.

2) 메모리 할당 여부를 확인할 수 있도록 함수를 짜자.

/* General process initializer for initd and other process. */
static bool process_init(void) {
  struct thread *curr = thread_current();

  /* Set as user task. */
  curr->mode = USER_TASK;

  /* Create file descriptor table. */
  curr->fdt = palloc_get_page(PAL_ZERO);
  if (curr->fdt == NULL) return false;  // 🔥 여기
  return true;
}

다음과 같이, 함수 내에서 메모리 할당을 할 경우, 할당 성공/실패에 따라 bool 또는 int 반환값을 반환해 주어서 함수를 부르는 쪽에서 할당 여부에 대해 알 수 있도록 코드를 작성하는 것이 좋다. malloc, palloc, calloc 등의 함수를 쓸 때는 반드시 실패 가능성을 염두에 두어야 한다. (이전에 C를 처음 배우면서, 'malloc으로 할당받은 포인터에 대한 NULL check를 습관적으로 해라' 라고만 배웠는데, 그 이유와 필요성을 이해하기보다는 기계적으로 적용만 하고 있었다. Pintos 프로젝트를 하면서 실제 할당 실패의 상황을 예외처리하는 것이 정말 너무너무나.. 중요하다는 것을 체감할 수 있었다.)

3) 예외 처리의 실행 지점을 잘 배치하자.

int dup2(int oldfd, int newfd) {
  if (!is_valid_fd(oldfd)) return -1;
  if (!is_valid_fd(newfd)) return -1;

  struct file **fdt = thread_current()->fdt;

  if (oldfd == newfd) return newfd;
  if (fdt[oldfd] == NULL) return -1;

  /* If newfd already has a file, close. */
  if (fdt[newfd]) {
    close(newfd);
  }

  /* If standard i/o, just copy value. */
  if (is_file_std(fdt[oldfd])) {
    fdt[newfd] = fdt[oldfd];
    return newfd;
  }
  ...

위 함수에서 standard I/O 식별자의 값을 복사해주는 부분과, fdt[newfd]가 열려 있는 파일이라면 먼저 닫아 주는 부분이 순서가 바뀌어 있다면 메모리 누수가 발생한다. 즉시 리턴하도록 예외 처리를 할 경우 특히나 리턴 전에 자원이 모두 할당 해제되었는지 확인하는 것이 중요하다.

세마포어, 락과 같은 동기화 메커니즘 역시 유사하다. 정상적인 시나리오뿐만 아니라 예외 처리 로직에서도 락을 잘 release할 수 있도록 해야 한다. 특히, 프로세스가 비정상적인 오류 (ex. segmentation fault)로 종료될 경우, 그 전에 소유하고 있던 메모리, 락, 세마포어 같은 자원을 모두 반환하도록 작성해야 안전하다.

😇 무엇을 느꼈나요

이전의 디버깅 방법으로는 누수 지점을 찾기 힘들다는 점이 가장 난감한 부분이었다. Fault가 나거나, 의도했던 실행 지점까지 코드가 실행되지 않은 경우 log를 찍어보면서 디버깅했고, 보다 복잡한 로직의 경우 gdb를 활용해 한 줄 한 줄 값을 검사할 수 있었다. 하지만 메모리 누수의 경우, 코드를 눈으로 훑어보며 로직을 체크해야 풀리는 부분이 있었던 것 같다. (특히 Out of Memory 테스트는 메모리가 허용하는만큼 fork를 하기 때문에, 디버거로 따라가기에는 무리가 있었다.) 코드에서 잘못된 로직을 발견하고 수정하는 것에 시간이 생각보다 훨씬 많이 걸렸는데, 결과적으로 장장 5시간(+a)의 디버깅 끝에 발견한 누수 지점은 다음과 같았다.

/* Open a new file. */
int open(const char *file_name) {
  if (file_name == NULL) return -1;
  struct thread *curr = thread_current();

  int fd = allocate_fd();

  struct file *file = filesys_open(file_name);
  if (!is_valid_fd(fd)) return -1; // 🔥 여기

  if (file == NULL) {
    free_fd(fd);
    return -1;
  }
  curr->fdt[fd] = file;

  return fd;
}

표시된 라인의 코드를 한 줄만 위로 올리면 누수가 발생하지 않는다. file descriptor table이 모두 할당된 경우 allocate_fd()는 -1을 반환하는데, 이 경우에는 정상적으로 파일을 열지 못했으므로 -1을 리턴하도록 코드를 작성했다. 문제는 그 전에 열어 둔 파일을 닫는 부분이 없다는 것이다. 따라서 fd값에 대한 validation을 먼저 하고, 파일을 열도록 해야 한다. 일반적으로 하나의 자원을 할당했으면, 즉시 할당 여부에 따라 예외처리를 하도록 코드를 짜는 것이 좋을 것 같다.

이전의 테스트에서는 '돌아가는 코드'를 평가했다면, Out of Memory 테스트는 코드의 안전성을 평가한다는 점에서 까다로웠던 것 같다. 자원 할당/해제를 잘 고려하며 코드를 짜는 것이 이미 작성된 코드에서 누수 지점을 디버깅하는 것보다 훨씬 쉽다는 점에서, 애초에 코드를 잘 짜는 것이 좋다. 특히 1. 함수가 리턴되는 모든 상황에서 할당된 자원의 해제가 이루어져야 할 수 있다는 것과 2. 할당의 성공/실패 여부를 반드시 체크하고 로직을 짜야 한다는 것을 꼭 기억하자. 할당에 실패할 경우 로그를 남기는 것도 방법인 것 같다.

---

oom 테스트를 마지막으로.. 어찌저찌 Project2의 테스트를 all pass 했다.. test case가 부실한 경우가 많은 것 같지만 어쨌든 통과..