Valgrind

출처: http://www.yoonkn.com/valgrind

http://en.wikipedia.org/wiki/Valgrind 별생각없이 릭잡는 용도로만 써왔는데 이게 오묘하구나. 일종의 VM 역할을 해서 인스트럭션을 훔쳐보면서 수정까지 해주는 일종의 프레임웍 이더라. 그냥 빌드후 릭잡는 용도로만 써왔는데 좀더 신경써서 사용해봐야 겠다. valgrind 자체는 일종의 프레임웍이고 이 프레임웍위에서 도는 여러 툴들이 있는데 각각의 툴이 하는 역할만 대강 적어놓는다. 사용법은 아주 쉬우니 어떤 툴이 있다는 정도만 기억해주면 사용하는데 문제 없다. memcheck http://valgrind.org/docs/manual/mc-manual.html 기본툴. 메모리를 잘못 사용하는 버그를 잡아내는데 사용된다. cachegrind http://valgrind.org/docs/manual/cg-manual.html 이건 좀 묘하군... 돌려보면 캐시미스율 등을 보여주는데 이게 인텔의 Vtune 처럼 CPU 가 날리는 진짜 이벤트를 가지고 보여주는게 아니고 일종의 캐시 시뮬레이션으로 유추해낸 결과. CPU 가 하드웨어적으로 해주는 브랜치 프리딕션이나 캐시 프리페치까지 제대로 시뮬레이션 해줄까?? 어쨌거나 캐시히트까지 고려하면서 개발하는건 내 능력밖이니 그냥 기억만 해두자. callgrind http://valgrind.org/docs/manual/cl-manual.html 프로파일러. 프로파일링 정보를 텍스트로 보는것은 효율이 안좋으니 GUI 를 써먹자. KCachegrind 참고 helgrind http://valgrind.org/docs/manual/hg-manual.html 흠 쓰레드사용시 에러를 잡아주는 툴. 인텔 쓰레드 체커같은 넘이겠군. 멀티쓰레딩은 안쓰는게 좋다는 주의라 이걸 앞으로 쓰게 될지는 의문. 좀 시원찮은 방법으로 OpenMP 를 지원하는듯 한데 그럼 곧 쓰게 될지도 모르겠다.. 어쨌거나 이정도까지 필요한 상황이 온다면 인텔 쓰레드체커를 쓰는게 더 좋겠지. helgrind 란 이름이 hell 에서 나왔다면 정말 이름 잘지은듯. 원래 사람머리는 멀티쓰레드 짜라고 달려있는게 아니다. 정말 필요한 경우만 최소한으로 쓰레드를 써먹자. massif http://valgrind.org/docs/manual/ms-manual.html 힙 프로파일러. 자기가 만든 프로그램이 얼마나 메모리를 먹는지 물어보면 대답못하는경우가 태반이다. 만약 그런 경우가 온다면 이걸로 얼렁뚱땅 돌려서 알려주자. 몇가지 알아둘점 STL 등을 쓸때 메모리 할당/해제가 바로바로 이루어지지 않고 풀링을 사용하는 allocator 등을 통해 구현되어있는 경우가 있는데 이경우 멤체커가 오진을 할수 있다. FAQ를 참고해서 풀링을 끄고 빌드해서 진단을 해보자. 또는 --show-rechable=yes 옵션으로 종료시 남은 메모리에 대한 진단 메시지를 끄는 방법도 있다. 자식 프로세스까지 멤첵을 돌리려면 --trace-children=yes 옵션을 추가한다. FAQ 스태틱으로 잡힌 배열이나 스택에 잡힌 배열의 경우엔 체크 불가능. 이미 빌드가 된 후의 바리너리를 가지고 체크를 하니까 크기를 알기 어렵겠지.. valgrind 는 오버헤드가 너무 큰데 ( 문서에 의하면 툴에 따라서 30배~100배까지도 ) 잘써오던 gprof 나 oprofile 등도 같이 쓸 생각을 해두자. 이글을 적는 현재는 oprofile은 아직 안써봤다. OProfile로 퍼포먼스 병목현상 분석하기 글을 참고하자.