왜냐하면..
실질적으로 제가 LOG를 호출할때
LOG("[C->S] PACKET");
LOG("==========");
이런식으로 작성을 했는데..
이 부분에서 에러가 발생을 합니다..
이것도 자주 발생하는게 아닙니다..
가끔 발생하닌까.. 문젭니다..
분명 다른 부분인거 같은데 어디인지를 알 수가 없네요..
제 경험상 이런 것은 (대부분의 경우) 어딘가 다른 곳에서 memory를 잘못 건드려서 나타났습니다. 운이 좋아서(?), seg fault가 나와야 할 곳에서 제대로 seg fault가 나와 준다면 참 좋겠습니다만, 프로그램 규모가 조금 커지면, 잘못된 memory access를 하더라도 내가 사용 가능한 공간을 access하는 바람에, 잠재적 오류로 묻혀 버렸다가 엉뚱한 놈을 망가뜨려서 이상한 곳에서 죽어버립니다.
이럴 때 유용한 것이 efence입니다. 메모리 allocation을 할 때 앞뒤로 protected area를 만들어서 조금 잘못된 access를 할라치면 그냥~ 확 죽어버립니다. Debugging 하기가 쉬워지죠. 단, 실행 속도가 굉장히 많이 느려져서, timing과 관련된 memory 오류가 나오는 경우 여전히 미궁 속으로 빠져들게 됩니다. (gugudan님께서 socket programming을 하시는 것 같은데, 어쩌면 딱 그런 경우일지도 모르겠습니다. efenece로 잡으려고 하면 실행속도가 늦어져서 error condition이 안 생기는... ㅡ.ㅡ)
efence가 설치되었을 경우, 사용법은 man efence해서 보실 수 있습니다. compile을 다시하거나 뭐 그럴 필요가 없어서 편합니다.
^^;
제생각에는 예외처리 루틴이 필요할거라 생각이 듭니다^^;
지금 코딩을 C 또는 C++로 하셨는지 모르겠지만 ^^:
c++이라면 try . catch로 잡으시면 되겠구
C라면 모질라에 bug tracker가 c에서도 되는지 모르겠지만 ^^:
된다고 생각이 들어서 한번 추천해 드립니다.
http://www.bugzilla.org/
에 가셔서 한번 확인 해보시기 바랍니다.
그럼
발생한 core를 가지고 디버거를 걸어서 해당 라인을 찾아서 검증해 보시
발생한 core를 가지고 디버거를 걸어서 해당 라인을 찾아서 검증해 보시기 바랍니다.
각 변수값도 확인해 보시고 포멧지정자와 맞게 되었는지도 확인해 보세요.
추측으로는 스레드 모델로 변경했을 때 수행되거나 추가된
로그 메시지 등을 출력하실 때 format 지정자가 안 맞아서 그런 것이 아닌가 생각됩니다.
gcc 를 쓰신다면
처럼 수행해서 잘못된 포멧지정자가 없는지 확인해보세요.
로그함수를 가변인자를 통해서 만들었을 때에도
보통 내부적으로 vsprintf나 vns, vf 계열을 사용하실 것으로 추측되는데,
매크로를 통해서 로그함수를 잠시 printf 계열로 바꾸어서 -Wformat을 돌려보세요.
에러가 나는 부분이 에러가 나는게 아닌건 확실합니다.
왜냐하면..
실질적으로 제가 LOG를 호출할때
LOG("[C->S] PACKET");
LOG("==========");
이런식으로 작성을 했는데..
이 부분에서 에러가 발생을 합니다..
이것도 자주 발생하는게 아닙니다..
가끔 발생하닌까.. 문젭니다..
분명 다른 부분인거 같은데 어디인지를 알 수가 없네요..
Re: 에러가 나는 부분이 에러가 나는게 아닌건 확실합니다.
제 경험상 이런 것은 (대부분의 경우) 어딘가 다른 곳에서 memory를 잘못 건드려서 나타났습니다. 운이 좋아서(?), seg fault가 나와야 할 곳에서 제대로 seg fault가 나와 준다면 참 좋겠습니다만, 프로그램 규모가 조금 커지면, 잘못된 memory access를 하더라도 내가 사용 가능한 공간을 access하는 바람에, 잠재적 오류로 묻혀 버렸다가 엉뚱한 놈을 망가뜨려서 이상한 곳에서 죽어버립니다.
이럴 때 유용한 것이 efence입니다. 메모리 allocation을 할 때 앞뒤로 protected area를 만들어서 조금 잘못된 access를 할라치면 그냥~ 확 죽어버립니다. Debugging 하기가 쉬워지죠. 단, 실행 속도가 굉장히 많이 느려져서, timing과 관련된 memory 오류가 나오는 경우 여전히 미궁 속으로 빠져들게 됩니다. (gugudan님께서 socket programming을 하시는 것 같은데, 어쩌면 딱 그런 경우일지도 모르겠습니다. efenece로 잡으려고 하면 실행속도가 늦어져서 error condition이 안 생기는... ㅡ.ㅡ)
efence가 설치되었을 경우, 사용법은 man efence해서 보실 수 있습니다. compile을 다시하거나 뭐 그럴 필요가 없어서 편합니다.
저도 비슷한 의견인데요.
메모리 관련 오류일 가능성이 높습니다.
죽는 부분 전에 실행되는 코드들을 다시한번 따라가면서 코드 리뷰해보시고 그래도 잡히는게 없다면 부분적으로 코드를 실행하지 않고 테스트를 해보는 것도 어느 부분이 문제인지 알아낼 수 있는 방법 입니다. (소거법)
메모리 버그 잡는 툴들도 부하가 큰경우는 쓸모가 없는 경우가 많습니다.
정말 힘들죠.
멀티 쓰레드 프로그래밍에서 메모리 버그를 만들어내는 프로그래머는 자르라는 말이 있을 정도로 디버깅이 어렵습니다. 흑흑..
Never Ending 삽질.
ymink 님 말씀에 한표~오류난 부분의 이전 실행코드의 버그인듯 합
ymink 님 말씀에 한표~
오류난 부분의 이전 실행코드의 버그인듯 합니다.
버퍼 언더/오퍼 플로우 같은데 efence 를 사용하실 수 있는 상황이라면 efence 를 사용해 보세요.
윗 분들의 말씀에 덧붙여 ...Thread Safe 한 함수를 쓰는게 좋
윗 분들의 말씀에 덧붙여 ...Thread Safe 한 함수를 쓰는게 좋다고 합니다
efence는 설치가 안되어 있더군요..
Singleton을 이용해서 log를 만들었고..
그 log에 필요한 때마다 mutex를 걸었습니다.
이게 문제가 되는지요?
지금 Singleton을 뺴닌까.. 에러는 나오는거 같지는 않는데..
언제 나올지는 장담은 못하겠지만..ㅜ.ㅜ
그리고 thread safe한 함수를 쓰고 싶은데..
이미 STL을 쓰고 있습니다.
thread에 safe하지 않는 STL을 사용해서
생기는 버그일까봐.. mutex를 확실하게
해주고 있습니다.
돈 벌어야 하는데 벌써 잘리면 안되요..
^^
이런종류의 디버깅은 힘듭니다.
그래서 보통적으로 bug trakcer같은 프로그램을 같이 이용합니다.
제가 위에 적은 bugzilla도 그런 프로그램 입니다.
일단 약간의 overhead가 있더라도 try catch문을 활용하시기 바랍니다.
그러면 거의 대부분의 에러가 잡히기 때문에 그때 그때 로그를 처리 하셔도 됩니다.
그리고 stl 은 thread safe하지 않습니다.
혹시 모르니 boost의 lock 함수를 같이 이용해보시기 바랍니다. ^^:
mutex 하시는쪽에 버그일수도 있으니 그쪽도 확인 해보시기 바랍니다.
그럼 ^^;
댓글 달기