데드락 걸렸을때, 동적 라이브러리 함수 추적을 어떻게 할수 있을까요?
안녕하세요.
스레드 프로그래밍을 하는데, glibc의 pthread_mutex_lock.c 자체를 직접 바꿔서 테스트를 해보려 합니다.
app 프로그램은 스레드가 여러개 돌면서, 락을 사용하는 것들이고 그래서 경쟁이 있습니다.
pthread_mutex_lock.c 의 파일 자체를 좀 바꿨더니, 한스레드가 락을 먹고는 unlock 이 되지 않고, 다른 스레드들은
그냥 cond_wait에서 자고 있습니다.
..
원래의 pthread_mutex_lock() 라이브러리 함수 안에 제가 이것저것 다른 함수를 넣었었고,
어디선가 락을 반환하지 않고 죽는가 해서 추적을 하려고 하는데, 제가 만든 함수 중에 어디까지 가서 죽은지를 못찾겠네요.
ltrace나 gdb 를 다 사용해 봤는데, 어디서 죽은지를 모르니, 브레이크 포인트를 어디로 둬야 할지도 모르겠고,
ltrace도 끝나지 않아서, 결국 ctrl+c 로 나오는 수 밖에 없네요. gdb로 따라가도, pthread_mutex_lock까지는 나오는데, 그 함수 안에서
다른 곳으로 분기하는 곳(예를 들어 제가 pthread_mutex_lock.c 라이브러리 파일 안에 삽입한 a(), b() )은 찾을수가 없네요.
분명히 디버깅을 위해 printf를 보면, 제가 삽입한 다른 코드로 가서 죽은것데 말이죠.
차라리, 메모리 관련 실수거나, segmentation falut면 그나마 낫겠는데, 락을 원래대로 돌려 놔야하는 알고리즘 어딘가가
문제가 된거라, 어디가 문제인지 찾기가 어렵네요.
고수님의 조언을 부탁드립니다.
테스트용 에러체크 뮤텍스를 쓰시면 됩니다.
데드락 오류가 있을 경우에는 뮤텍스 초기화시, 에러체크가 가능한 뮤텍스로 초기화하면 됩니다.
그리고 에러체크가 모두 끝나고 제대로 작동한다면 다시 노멀 뮤텍스로 바꾸시면 됩니다.
========================================
* 부분이 전체를 대변하는 하나의 속성일때 진리이다.
영속적이지 못한 것은 전체가 될 수 없다.
========================================
* The truth will set you free.
댓글 달기