연말에 10일간의 휴가가 꿈결처럼 지나가고 나서, 2주간의 야근, 그리고 이번 주에도 업무량이 많아서 괴로워하고 있다.
이번 주 업무량에 + α를 더해준 버그들을 소개해보겠다.
C++ 삽질
작년 끝 무렵에 팀에 합류한 후배 i 군이 서버 군을 대상으로 테스트를 돌리는 툴을 만들었다. 이걸로 몇몇 서버를 테스트했는데, 타이머 이벤트 처리하는 부분에서 메모리 릭이 생기거나 크래쉬가 나는 것이다 Orz. 덕분에 어제 야근.
삽질했던 이유는, 기존에 별도 라이브러리였던 타이머 구현체를, 기본 라이브러리 안으로 가져오면서 boost 의존성을 뺐는데, 이때 boost::shared_ptr 를 코어에서 빼내었다. 근데 이 새 구현체에서 스마트 포인터의 의미적인 부분(semantics)을 완전히 동등하게 구현한 게 아니라서 특정 경우엔 메모리가 새거나, 프로그램이 죽거나 한 것.
결국 긴 시간의 코드 리뷰 + 약간의 의미 바로잡기 + 약간 긴 테스트로 수정 완료.
Python 삽질
내가 작업하는 프로젝트 하나의 결과물인 바이너리와 몇 가지 도구를 다른 팀에 건sp주게 되었다. 근데 여기에는 Python 으로 작성한 몇 가지 도구가 있는데, 이걸 그냥 주자니 파일이 너무 많아서, py2exe 로 하나로 합쳐봤다. 이제 일어난 문제…
- 툴 중에 다른 프로그램들을 로컬 혹은 리모트에 띄워 주는 툴이 있다
- 이 툴을 실행 시켰 더니 프로세스를 계속해서 실행해서 윈도우즈 서버가 사망 ((이건 결과적으론 *nix 류에서 결과 검사 없이 fork() 하는 코드 비슷하게 되어버렸다))
- 문제를 찾아보니 py2exe 결과물에선 sys.executable 이 py2exe 의 출력과 동등하게 되고
- 내가 짠 툴에서는 .py 확장자인 녀석을 실행할 때, 실행 바이너리를 sys.executable 을 썼고
- 덕분에 py2exe 결과물은 자기 자신을 무한 fork()…
Orz.
사실 이 문제는 python subprocess의 win32 구현체가 CreateProcess를 써서 생기는 건데 흑흑. 그냥 ld 처럼 해주면 안 되겠니?
이건 아직 해결은 안 하고 미뤄뒀지만, 해결하려면 i 군 말마따나 python.exe 로 .py 를 실행하게 하지 말고, 저것도 py2exe로 바꿔놓고 해야 할듯함?
덤으로, 이제까지 이런게 있는 줄도 몰랐는데(…), isinstance 란 내장 함수가 있더라. 나 이거 때문에 try: … except: 로 짠거 몇 개 있는데…
이게 프로그래머의 삽질 + 인생인가? 흑흑
