나의 친구 Segmentation fault

   C++을 배우던 초창기에는 seg. fault^[각주:1]만 뜨면 가슴이 덜컥, 내려 앉았었는데, 요즘엔 그냥 "이놈, 오랜만이다"란 느낌 정도. ㅋ 피할 수 없는 것이라면 두려워하기보다는 친해지는 편이 나을지도 모르겠다. 나는 C++로 코딩을 함에 있어 seg. fault가 결코 발생하지 않도록 프로그래밍 할 수 있을 정도의 실력은 갖기 힘들다고 생각하니까. 예전 언젠가, 랩에 계신 한의사 선생님하고 이런저런 얘기를 하다가, 한의학 쪽에서는 암을 우리 몸에 잠시 들린 손님 정도로 간주한다고. 말하자면 서양과학을 하는 나로선 좀 의아했는데, 그 이후로 '암세포'를 보는 시각이 조금은 바뀌어서, 이 자식들이 사람 죽이려고 기를 쓰는군, 이 아니라, 이 놈들도 지들 나름대로 살아 나가려고 그러는 것이군, 으로 생각하게 되었다.

   segmentation fault도 비슷한데, 마음을 달리 먹었다고 크게 바뀌는 것은 없어졌지만, 그래도, 일단 겁부터 나던 것도 없어졌고, seg. falut가 튀어 나와도 별로 짜증이 나지 않는다. 앞에 말했듯이, 오히려 조금 반갑다고 해야 하나... 요즘에는 STL을 많이 사용해서 pointer에 메모리 할당할 일도 별로 없어서 그런지, seg. falut가 정말 가끔 나오는 것도 있지만, 그런 경우를 생각해 보면 꽤나 머리 아픈 코딩을 하고 있을 때임에도 불구하고, 'seg. falut는 내 친구'라고 생각하면 스트레스가 거의 없다. 익숙해지면, seg. falut가 떠도 대충 어디에서 떴을 것이라는 점이 감이 잡히고, 그리 오랜 시간 걸리지 않아서 대부분 해결하게 된다, 물론 단일 쓰레드에서만. >.<" 더불어, 윈도우즈에서 할 경우에는 디버거와 GUI가 맞물려 있으니 쉽게 에러 난 위치를 찾을 수 있고, 터미널에서 gcc로 할 때라도 굳이 gdb를 쓰지 않아도 몇 군데에다가 std::cout (ㅋㅋprintf의 C++ 버전인가?) 밖아 놓고 테스트 두어번 해보면 어디서 왜 났는지 쉽게 찾을 수 있고.

   왜 seg. falut가 뜰 때는 꽤나 머리 아픈 코딩을 하고 있을 때냐 하면은, 그런 경우는 주로 STL 을 쓰다가 메모리나 시간 문제 때문에 pointer를 사용하는 것으로 바꾸고 있을 때일 확률이 높기 때문이다. 지금도 비슷했는데, multimap 을 사용하던 것을 2차원 배열을 동적할당해서 사용하는 것으로 바꾸던 중에, 실로 오랜만에 seg. falut가 나왔던 것이다. log 가 정말 대단하긴 한데, 역시나 O(1) 에 비할 바는 아닌듯. 그래프를 처리하면서, adjacent matrix 를 사용하는 대신 multimap 으로 edge 정보를 다 갖고 있게 했었는데 (간단해서), 역시나 node 수가 많아지면 급격히 오래 걸린다. 더구나 하는 작업은 O(N^3) 이라서 알고리즘 자체로도 오래 걸리고, multimap 형태의 자료를 만드는데도 꽤나 오랜 시간과 메모리가 사용되었던지, 바꾸고 난 코드로 테스트 할 때는 2분 걸리는 것이 바꾸기 전 코드로는 1시간 30분 정도가 걸렸다. 역시 일이 조금만 복잡하거나 커지면 STL로는 부족하다.

1. segmentation fault [본문으로]