멀티프로그래밍 블로그

오늘 TSF (Text Service Framework)를 지원하는 Application을 개발하는데 있어, 디버깅 하는데  큰 문제가 있음을 알아 냈습니다.

먼저 자세한 설명을 하기 전에 증상부터 알아 봅시다. 아래 소스는 Vista SDK에 TSF 예제로 포함된, TSFAPP의 TEXTSTOR.CPP의 일부입니다. InsertTextAtSelection 함수는 새로운 글자가 입력될 때 마다 호출되는 함수입니다. 함수 시작 부분에 메모리 주소 0 에 쓰기를 시도하여 Access Violation을 유발 시켜보았습니다. 이것은 심각한 버그가 있는 것을 시뮬레이션 하는 것입니다.

이제 TSFAPP.EXE를 컴파일시켜, 한글을 입력해 봅시다.  그런데,  예상과 달리 이 어플리케이션은 크래시되지도 않고 우리가 흔히 보는 윈도우즈 에러 리포트 다이얼로그도 나타나지 않습니다. 단지 원하는 한글 입력은  되지 않습니다. 이것이 왜 디버깅에 문제가 되는 지, 아마 어느 정도 짐작하였을 것입니다. 어플리케이션이 제공하는 TSF 인터페이스 내부에, 아무리 심각한 버그가 있어도 프로그램이 죽거나 에러를 리포트하지 않는다는 것입니다.  이유는 무엇일까요? 다름 아닌 윈도우즈의 TSF입력 지원 모듈이 자체 예외처리기를 가지고 있기 때문입니다.

따라서, 디버거를 처음에 attach시켜 프로그램을 실행하지 않는 한, access violation과 같은 심각한  버그가 있어도, 어느 순간 입력에 이상이 생기는 현상만 나타나며, 원인을 알아내기 어렵다는 점 입니다. 특히 어플리케이션이 자체 예외처리기(SEH)를 가지고 콜스택을 로그파일로 만들거나 덤프파일을 만드는 것이 불가능해 집니다. 따라서, 어플리케이션 버그로 인한 입력 문제가 발생함에도 불구하고 사용자나 개발자는 OS에 문제가 있는 것으로 오인할 가능성도 많습니다.

윈도우 TSF 모듈이 자체 예외처리기를 가지는 것을 확인하기 위해서, 우선 위에서 만든 TSFAPP.EXE를 실행해 봅시다. 그리고 VS에서 Attach to Process를 선택하거나, 이 프로세스의 ID를 알아낸 다음, "ntsd -p <프로세스 ID>"와 같이 커맨드라인 디버거를 이용하여 디버거를 attch 합니다. 이제 한글을 입력하려고 하면 디버거에서 이 메모리 오류(Access Violation)을 캐치함을 알 수 있습니다. 이것은 First chance exception 입니다. 여기서 다시 계속 진행시키기 위해 디버거에서 "go"를 선택하면, 아래와 같은 콜스택을 볼 수 있습니다.

TSF 핵심 모듈인 MSCTF.DLL이 자체 exception handler를 가지고 있는 것을 알 수 있다. 여기서 다시 "go"를 하면 프로그램은 종료되지 않고 계속 실행된다.

여기서 CicExceptionFilter가 EXCEPTION_EXECUTE_HANDLER 값을 리턴하는 것을 짐작할 수 있습니다. 즉, MSCTF 자체 예외처리기에 걸리면 다른 SEH는 이것을 알지 못합니다.  내가 아무리 최고의 unhandled exception handler를 가지고 있다 해도 무용지물입니다. 여기서 한가지 해결책은 XP이후부터 지원되는 Vectored Exception Handler를 사용하는 것입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.