DOSBox에서 vim을 사용하면서 나온 문제였는데, 특이하게 Linux환경에서만 발생하는 듯 합니다. (MS-Windows에서는 문제가 없음을 확인했으며, 문제의 발생을 확인한 환경은 Ubuntu 10.04였습니다.)
우선 스크린샷으로 문제를 확인해 보겠습니다.
 |
| vim으로 test.txt라는 파일을 새로 만듭니다. |
 |
| 파일을 저장하면 정상적으로 저장됩니다 |
 |
| 해당 파일인 TEST.TXT가 만들어진 것을 확인할 수 있는데, read-only입니다. |
 |
| 같은 파일을 수정해서 다시 저장해보겠습니다. |
 |
| 저장이 안됩니다!! |
DOSBox에서 생성된 파일은 read-only로 생성이 되고, 그래서 수정이 안된다?
그러면 당연히 DOSBox의 문제라고 생각할 수 있으나 vim이 아닌 다른 에디터에서 수정한 후 저장하면 저장이 됩니다.
단지 vim만 저장을 못합니다.
그럼 vim의 문제일까요?
MS-Windows 환경의 DOSBox에서는 문제가 없습니다.
Linux환경이라 해도 VirtualBox에 MS-DOS를 설치해 vim을 사용하면 문제가 없습니다.
아마 vim도 다른 에디터와는 뭔가 다른 방법으로 파일을 저장하고 있으며,
DOSBox도 Linux 환경에서는 파일 I/O에 관해 일부 기능에 버그가 있는 것이 아닌가 싶습니다.
여기에서 발생하는 재미있는 문제가 하나 있습니다.
vim에서 문제가 발생하는 부분을 디버거로 트레이스 할 수 있겠지요.
하지만 두개의 제품이 연계하면서 발생하는 문제를 하나만 디버깅해서는 제대로 잡을 수 없을 겁니다.
따라서 vim에서 문제가 발생하는 부분이 다시 DOSBox로 어떻게 이어지는지,
혹은 반대로 DOSBox에서 발생한 문제가 어떻게 vim으로 이어지는지를 확인해야 할 겁니다.
이런 연계 문제를 디버깅하려면 어떻게 해야 할까요?
Linux에서 gdb로 DOSBox를 디버깅하면서 DOSBox에서는 터보디버거로 vim을 디버깅하나요?
gdb와 터보디버거가 연동할 수 없는 환경이니 의미가 없을겁니다.
만약에 DOSBox에 내장디버거가 있어서 vim을 자체 디버거로 디버깅할 수 있다면 어떨까요?
그 상황에서도 gdb가 디버깅하는 DOSBox는 정상적인 루틴이 아닌 내장디버거에 의해 각종 trap이 설치된 변형된 루틴일 수도 있어 오히려 디버깅이 어려울 수도 있을겁니다.
이상적으로는 DOSBox를 디버깅하는 디버거가, DOSBox라는 에뮬레이터와 그 안에서 돌아가는 vim이라는 application이 존재하는, 일종의 nested? embedded?임을 인식해야만 할 겁니다.
현실적으로는 디버거가 환경을 인식한다 하더라도 효율적인 디버깅 방법도 고민스러우며, 얼마나 다양하게 쓰일 수 있는냐도 의심스러운 부분입니다.
따라서 통상적으로 분산 시스템의 연계 문제를 디버깅할 경우에 synchronization을 방해하지 않고 디버깅하는 방법은.......
메시지를 기록해서 이를 분석하는 방법입니다.
쉽지는 않겠지만 한번 디버깅을 해 보겠습니다.
