The Incops Strikes Back!

제목이 뭔가를 떠올리게 한다면, 그건 다 오해다. (기다려달라?)

화요일 저녁에 퇴근하려는데, 옆자리의 개발자 분이 나를 부른다. 내가 개발하는 라이브러리에서,

“Debugger 붙여놓고 띄워보면 First chance exception이 나요. Access violation 이고 0x0000 0000에 뭔가 쓰려고 합니다”

라고. ((First chance exception에 대해서는 MSDN 블로그의 이 글을 참고 하자.))

일단 해당 자리의 디버거 창에서 살펴본 봐로는, 내가 수 주 전에 추가한 WSASend 호출 횟수 줄이는 코드에서 나온 문제인 듯 했다. Send-Queue에 패킷이 여러개 쌓이면, 이걸 모아서 전송하는 루틴을 추가했는데, 이 안에서 저 first-chance exception이 발생. ((실제로 구현한 최적화는 이런 내용이다. MS Win32 WinSock 에 존재하는 시스템 콜인 WSASend 는 좀 특이하게(?)도 – 혹은 일부 UNIX 시스템에 익숙한 사람이라면 sendv() 함수를 생각하면 된다 – 하나의 바이트 스트림을 전송하는게 아니라, 일련의 바이트 스트림을 전송하게 해준다. 즉 pointer + length 를 이용하는게 아니라 pointer + length의 배열을 인자로 받아, 이를 전송해 준다. 그래서 Send-Queue에 쌓인게 많으면, 이걸 여러 번 쏘거나(system-call 수가 많다), 하나의 배열로 합치거나(추가적인 메모리 할당 및 복사가 필요하다)하지 않고, 단순히 이 버퍼들에 대한 주소 + 길이 쌍을 배열에 집어넣고 WSASend를 호출하는 것.)) 일단 화요일엔 집에 어머니도 와 계시고 해서 바로 퇴근하고 다음 날 오전에 추적하기로 했다.

First chance exception 이 발생했다곤 해도, 프로그램이 실제로 크래시하지 않는 걸로 봐선, 어딘가에선 처리 되고 있단 얘기니 좀 안심하고 다음 날 디버깅 시작. 출근해서 코드를 열심히 들여다 봤다. 대체 어디서 문제가 생길까? 일단 내 머신에선 재현이 안되더라. 그래서 일단 저 문제를 발견한 개발자가 출근할 때 까지 기다렸다. 그리고 얘기해주는 환경을 다 끌어 모아서(플랫폼 + 컴파일러 버젼을 맞춤) 테스트.

발생하지 않는다?!?!?!?!. 해당 개발자 자리에 가서 하면 한 번에 재현된다. 그래서 잘 알려진 WinSock 관련 first-chance exception 문제처럼, 이것도 MS가 포기(?)한 버그인가 싶어서 MS에 있는 모 선배에게 물어볼까 하고 있었다. 그래도 다른 선임분의 말을 듣고 다시 디버깅하는데, 콜 스택 모듈에 보니 수상한 dll 이 하나 있더라.

anywall3.dll 이게 뭘까? 저 네이밍으로 볼 때, 저주받을(…) 삼성 SDS의 인캅스(incops)를 연상케하는데… 여튼 몇 가지 테스트를 더 해본 결과:

Incops3 가 없는 시스템에선 당연히 저 DLL이 콜 스택에 안 보인다. 그리고 저 문제도 없다….

=_=

더욱 씨니어인 다른 개발자 분의 말로는, 정확히 같은 케이스는 아니지만, 인캅스 적용 후 그런 문제를 경험하고 있다고… 나는 계속 서버 쪽 개발만해서 x64 환경만 쓰다보니 — x64에선 인캅스가 안 돈다 – 다행히 안 겪은 것 뿐이었던 듯?

결론: 개발자의 시간과 노고를 갉아먹는, 내 컴퓨터 공학 석사/학사 학위를 걸고 쓸모 없는 프로그램인 삼성 SDS Incops 좀 쓰지 맙시다. 이 회사에서도 사실 상 사용을 포기한 툴이기도 하고 – 존재 의의 중 하나가 USB 로 파일 복사를 막는 기능이 있다. 근데 “전혀 막지 못하는 버그(헛점?)”가 있는데, 리포팅하고 나서 수 개월 후에 패치는 받았다는데, 전사 적용을 못 하더라. 그리고 이젠 다른 툴을 쓴다. 인캅스 자체는 꼭 설치하지 않아도 된다고 하더라…