Refreshing My Brain!!!!!

 개발을 하다보면 이런저런 버그를 접하게 됩니다.. 지난주에는 자체 Solution을 구입한 회사에서 upgrade를 하였더니 갑자기 message queue가 full이 난다면서 해결하라고 전화가 와서 일주일간 뺑이.. -_-;;

 문제인즉슨... 500tps정도로 테스트를 하는데 25분에 재현될때도 있고 6시간이 걸려 재현될 때도 있다고 하니... 게다가..  다른 곳에서는 잘 쓰는 version인데... 뭐가 문제일까... 하고 들여다봤으나.. 당체 알 수 없음...

 truss 로 떠봐도 계속해서 500tps 정도로 작업을 하고 있는 걸 전부 파일로 떨구거나 할수도 없고 stdout으로 보려니 속도가 느려져서 재현이 안될듯하여.. 여기저기에 한두줄 로그정도만 넣고 확인... 그래도 알수 없음.. OTL...  

 결국 truss로 file로 떨구면서 로그가 일정 사이즈 되면 다시 truss 돌게 하나 간다하게 코딩해서 돌리다 보니... 허허...

msgrcv(57344, 0xFFBEEA78, 4096, 0, IPC_NOWAIT) Err#35 ENOMSG
alarm(0) = 0
setitimer(ITIMER_REAL, 0xFFBEDB28, 0xFFBEDB18) = 0
sigaction(SIGALRM, 0xFFBED9A8, 0xFFBEDAD8) = 0
setitimer(ITIMER_REAL, 0xFFBEDB28, 0x00000000) = 0
  Received signal #14, SIGALRM [caught]
sigprocmask(SIG_SETMASK, 0xFF04CFB8, 0x00000000) = 0
sigprocmask(SIG_SETMASK, 0xFF058CE0, 0x00000000) = 0
setcontext(0xFFBED498)
sigprocmask(SIG_SETMASK, 0xFFBEDA28, 0x00000000) = 0
sigsuspend(0xFFBEDAA8) (sleeping...)
signotifywait() (sleeping...)
door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
lwp_cond_wait(0xFF0534E8, 0xFF0534F8, 0xFF04CD80) (sleeping...)
signotifywait() = 15
  Received signal #15, SIGTERM, in sigsuspend() [caught]
  siginfo: SIGTERM pid=25540 uid=100
lwp_sigredirect(1, SIGTERM, 0xFF00FC6C) = 0

 msgqueue에서 recv할 때 queue에 message가 없는 경우 alarm에서 신호를 제대로 처리하지 못해 발생하는 것이 아닌가.. -_-;;

결국.. 알고 보니... usleep()의 사용으로 인한 버그...;;

 truss의 system call이 호출된 내용으로 봤을때는... usleep을 사용하게 되면

1. signal을 설정

2. alarm이 동작

3. alarm을 중지하라는 signal을 받아서 interrupt

4. alarm 중지

5. signal 제거

인데... 

3. alarm을 중지하라는 signal을 받지 못해서 pending 되는 거였더라는... 전설이.. -_-;;

이런 일이 있을때마다.. 짜증이... 아우 식빵.. -_-;; 

사실 우리 회사 제품의 문제는 아니라 그 쪽에서 사용하는 api에서 사용하는 usleep이 문제인데... 뭐라 할말이 없...-_-ㅗ

또 다른 버그는 Optimize option 을 주었을 때만 발생하는 버그.. -_-;;

 -O3 옵션을 주고 컴파일을 했더니 memory address가 싸~악 정리되면서 다른 functino에서 memcpy 할때 invalid write adress 가 발생했었다는... 이 버그의 경우는 valgrind로 위치를 파악하고 해당 부분에서 사용되는 변수들의 주소번지를 일일히 확인하여 보다가 word boundary가 맞지 않는 부분을 찾아서 수정...

작년말쯤 발견한 극악의 버그...

제품에 사용되는 부분중에 두대의 서버간에 통신을 하는 부분에서 recv할때 data가 유실되는 듯한 모습이 보여서 확인했을 때, recv size라던가 데이터가 잘못된게 아닌... non-blocking할때 cpu usage를 줄이기 위한 nanosleep 부분이 너무 작아서 skip 되어버리는 버그가 있었더랍니다...

버그를 발견할때마다.. 느껴지는 후련함 + 허무함에 그만두지 못할듯...

다른 분들은 어떤 버그로 인해 고생을 하셨는지 궁금하군요...