yuchi's development

• 적어도 디버그 빌드에 한해서라도 어플리케이션은 반드시 명시적 종료가 있어야한다.
• 명시적 종료 상황에서 힙을 비롯한 모든 리소스가 완전하게 해제되었는지 체크할 수 있어야 한다.
• 무엇보다 heap이 손상되었는지를 체크할 수 있어야한다.

명시적 종료할때 이걸 체크하지 않으면 눈에 띄지 않는 버그가 계속 쌓임. 시한폭탄임.

실제로 내가 만들던 게임 서버에서 그런 사건이 있었다.

사내 테스트 하루 전날 팀 내 플레이 테스트를 마치고 가뿐한 맘으로 서버를 ‘우아하게’ 종료 시켰는데 Visual C++의 CrtCheckMemory()가 heap corruption이  발생했다고  알려줌.

그 상태 그대로 dump를 떠서…windbg에서 읽어다가 힙을 다 뒤짐. 힙을 덤프 떠서 텍스트 파일로 저장하고 각 블럭의 head와 tail을 비교해서 하나하나 추적하다가 링크 끊어진 위치 찾음.
다행히 그 손상된 블럭의 메모리 사이즈가 일반적이지 않은 사이즈라… 17xx바이트던가..

_CrtSetAllocHook로 훅 걸어서 힙메모리 할당할때마다 사이즈 비교해서 손상된 블럭이 어떤 구조체인지 찾음.
그 구조체 억세스 하는 코드를 찾음.

내가 만들어둔 인덱스 할당 클래스가 1부터 리턴해서 1을 빼서 사용하는게 막내 프로그래머가 0부터 리턴하는줄 알고 1을 안빼고 사용. 그래서 힙블럭을 깨먹음.
흔하게 발생하진 않지만 게임서비스 하면 100% 발생할 버그였다.

그래도 우리팀은 버그 없는 소프트웨어를 만들려고 엄청 노력하던 편이라 이렇게라도 잡았지. 다른 팀 코드들 보면 heap 메모리 줄줄 새는건 기본이고 종료할때 heap corruption이 떠도 아무도 신경을 안썼다.
그래서 디버깅 관련 문서도 만들어서 회사 내에서 배포했는데, 뭐 그래서 회사 분위기가 바뀌었냐 하면 절대 아니고.
싫은 소리 하는 사람은 미움 받게 마련. 재수없다고 욕만 오지게 더 쳐먹었다. 해당 문서(https://doc.co/4mJfse/HbHyae)는 기록 보존 차원에서 docs.com에 올려놨다.

하여간…

모바일 세상이 되면서 명시적 종료 없는 App life cycle이 대세가 되었다. 애플이나 다른 회사들이야 원래 디버깅 환경이 멀쩡할거라고 기대도 안하는데 디버깅의 최강자 MS의 플랫폼 마저 그런 똥같은 방식을 받아들였음.
그게 Windows Runtime -> UWP.
물론 난 그 안에서 가상의 명시적 종료를 만들어서 heap 체크 다 하곤 있긴 한데 영 불편함.