[NOTE] hex_dump 호출 위치가 문제가 되는 이유 - Week9-11-team03/Pintos-User-Program GitHub Wiki
Proposition
hex_dump를 load 함수의 마지막 시점에 호출하면 process_exec()에서 실행하는 것과 달리 커널 패닉이 발생한다.
Evidence
- 백트레이스에서 확인할 수 있듯이, 커널 패닉은
thread_current()
함수에서is_thread(t)
검증이 실패했을 때 발생했습니다. 이는 현재 스레드 구조체가 손상되었거나 유효하지 않은 상태임을 의미합니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html). - 백트레이스 호출 순서를 보면
hex_dump
→printf
→ 여러 콘솔 및 출력 함수들 →thread_current
→ **debug_panic
**으로 이어지는 것을 확인할 수 있습니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html). - 제공된 코드 스니펫에서 process_exec() 함수에서는 hex_dump가
do_iret(&_if)
직전에 호출되는 반면, load 함수의 마지막 부분에서 호출하면 문제가 발생합니다[1](https://velog.io/@ceusun0815/Pintos-KAIST-Project-2-Argument-Passing). - load 함수는 사용자 프로그램의 ELF 파일을 로드하고 메모리에 매핑하는 과정에서 여러 중요한 커널 자료구조를 다루는데, 이 시점에서 hex_dump를 호출하면 스택 오버플로우나 메모리 접근 문제가 발생할 수 있습니다[1](https://velog.io/@ceusun0815/Pintos-KAIST-Project-2-Argument-Passing)[[4](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/)](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/).
Extension
이 진술에서 확인할 수 있는 추가 명제는 다음과 같습니다:
- 스택 컨텍스트 차이: process_exec()에서 hex_dump를 호출할 때와 load 함수 내에서 호출할 때의 스택 컨텍스트가 다릅니다. process_exec()에서는 사용자 스택 설정이 완료된 후 호출하지만, load 함수 내에서는 아직 스택 설정 과정 중에 호출하게 됩니다[1](https://velog.io/@ceusun0815/Pintos-KAIST-Project-2-Argument-Passing). → 합리적인 증거가 아닌듯 함. 왜? 로드에서도 이미 다 끝나서.
- 메모리 상태 차이: load 함수 내에서는 ELF 파일을 로드하고 메모리를 설정하는 과정 중이므로, 이 시점에서 hex_dump를 호출하면 아직 완전히 초기화되지 않은 메모리에 접근할 가능성이 있습니다[1](https://velog.io/@ceusun0815/Pintos-KAIST-Project-2-Argument-Passing)[[4](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/)](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/).
- 커널 패닉의 원인: 이 상황에서의 커널 패닉은 NULL 포인터 역참조 또는 잘못된 메모리 접근으로 인한 것으로 보입니다. 특히 "assertion `is_thread(t)' failed"는 스레드 구조체가 손상되었음을 시사합니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html)[[4](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/)](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/)[[5](https://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/)](https://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/).
- 디버깅 함수의 안전한 사용 시점: hex_dump와 같은 디버깅 함수는 시스템 상태가 안정적인 시점에서 호출해야 하며, 중요한 메모리 작업 중에는 사용을 피해야 합니다[3](https://linuxembedded.fr/2019/12/storing-crash-data-of-the-linux-kernel-for-post-crash-debugging)[[4](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/)](https://www.ssh.guru/posts/200101-troubleshooting-kernel-panic/).
- 인터럽트 컨텍스트 문제: 백트레이스에서 console_locked_by_current_thread 및 lock_held_by_current_thread 함수 호출이 보이는데, 이는 인터럽트 컨텍스트에서 스레드 관련 작업을 시도할 때 문제가 될 수 있습니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html)[[3](https://linuxembedded.fr/2019/12/storing-crash-data-of-the-linux-kernel-for-post-crash-debugging)](https://linuxembedded.fr/2019/12/storing-crash-data-of-the-linux-kernel-for-post-crash-debugging).
- 메모리 할당 및 해제 관련 문제: 0xcc 패턴이 보이면 이미 해제된 메모리에 접근하는 문제일 수 있으며, 이는 load 함수 내에서 메모리 관리가 아직 완료되지 않은 상태에서 hex_dump를 호출할 때 발생할 수 있습니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html).
Comment
-
여전히 이유를 모르겠다. process_exec 함수 내에서 로드 직후 hex_dump(if.rsp, if.rsp, KERN_BASE - if.rsp, true); 호출하는 것과 로드 함수 내에서 hex_dump(if->rsp, if->rsp, KERN_BASE - if->rsp, true); 호출하는 것의 차이가 뭔지 모르겠다. 후자는 심각한 에러를 일으킨다.
왜 process_exec()에서는 문제가 없고 load()에서는 문제가 발생하는가?
이 질문에 대한 답은 두 함수의 호출 컨텍스트와 스택 상태의 차이에 있습니다:
- 스택 깊이 차이: load() 함수는 process_exec() 내에서 호출됩니다. load() 함수 내에서 hex_dump를 호출하면 호출 스택이 더 깊어지므로 스택 오버플로우 위험이 높아집니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html).
- 스택 사용량 차이: load() 함수는 ELF 파일을 로드하는 과정에서 이미 상당한 스택 공간을 사용합니다. 여기에 추가로 hex_dump를 호출하면 남은 스택 공간을 초과할 가능성이 높습니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html)[[3](https://cs162.org/static/proj/proj-threads/docs/faq/)](https://cs162.org/static/proj/proj-threads/docs/faq/).
- 메모리 상태 차이: load() 함수 내에서는 메모리 매핑 작업이 진행 중이므로, 이 시점에서 hex_dump를 호출하면 아직 완전히 설정되지 않은 메모리 영역에 접근할 수 있습니다[2](https://ics.uci.edu/~ardalan/courses/os/pintos/pintos_11.html).
- 인터럽트 컨텍스트: load() 함수 실행 중에는 특정 인터럽트 컨텍스트에서 실행될 가능성이 있으며, 이 상태에서 hex_dump가 호출되면 thread_current()와 같은 함수에서 문제가 발생할 수 있습니다