발생
프로젝트 2를 구현한 후 multi-oom을 제외한 모든 테스트 케이스에서 pass했다. 여기서 특이한 것은 pass 여부가 가상 환경 사양에 따라 갈린다는 점이었다. 도커로 로컬 노트북으로 돌린 나의 경우에는 multi-oom을 통과하지만, git clone으로 받아서 AWS에서 돌린 동료들은 전부 FAIL이 뜬다. 여기서 또 신기한 점은 AWS의 t2.large 서버에서 테스트해본 동료는 또 pass했다 ㅋㅋ. 아무래도 가상 환경의 메모리 용량에 따라 multi-oom이 터지는 걸로 추정된다.
다른 동료의 코드와 한참을 비교해보다가 동료가 해결해주었다.
솔루션
tid_t
process_fork (const char *name, struce intr_frame *if_) {
...
if (child->exit_status == TID_ERROR) {
sema_up(&child->exit_sema); // 여기가 추가됨.
return TID_ERROR;
}
}
- 자식 프로세스가 로드가 실패했다거나 에러가 떴을 경우, 자식 프로세스의 exit_status는 TID_ERROR를 가지고 있는데 이 때 fork를 호출한 부모 프로세스에게 TID_ERROR를 반환하면서 에러가 발생했음을 알려준다. 자식이 죽었으니 자식의 exit_sema를 풀어줬어야 했는데 안 해줘서 multi-oom에서 틀렸었다.
의문점
- 왜 메모리가 많은 가상 환경에서는 제대로 돌아가는가?
- 왜 multi-oom만 터지는가?
의문점이 2개나 남았다. 코드를 고친 이후 모든 가상 환경에서 multi-oom이 통과했기 때문에 sema_up의 문제가 맞다는 걸 알 수 있다. 그러나 자식이 터진 후 세마포어를 풀어주는 것은 꽤나 큰 문제인 것 같은데, multi-oom에서만 터졌다는 것이 신기하다. 부모가 자식 프로세스의 세마포어를 풀어주지 않으면 자식 프로세스는 죽지 못한 채 좀비 프로세스로 계속 살아있을텐데.. 신기하다.
메모리가 많은 가상 환경에서 터지지 않는 이유는 메모리 공간이 넉넉해서 페이지 폴트가 일어나지 않기 때문이 아닐까 추정된다. 자식 프로세스가 계속해서 살아서 자원을 낭비해도 어차피 공간이 넉넉하기 때문에 별 문제가 없는 것 같다.
'프로젝트 > Pint OS' 카테고리의 다른 글
[Pint OS] Lazy loading(1) (0) | 2023.06.18 |
---|---|
[Pint OS] System Calls (6) (0) | 2023.06.17 |
[Pint OS] System Calls (5) (1) | 2023.06.14 |
[Pint OS] System Calls (4) (0) | 2023.06.11 |
[Pint OS] System Calls (3) (0) | 2023.06.11 |