c/c++ segfault (core dumped) 디버깅 방법


(ㄴㅂㄷㄱㄷㄱ) #1

TLDR;;

$ coredumpctl list
$ coredumpctl gdb <optional-pid> 

서론

제가 요즘 심심풀이로 읽는 책이 너무 오래되서 그런가 (art of debugging)

코어라는 걸 소개하고 디버깅할때 유용하게 써먹을 수 있다고는 나오는데

정작 ulimit -c unlimited 라고 해도 코어 파일은 생성되지 않더군요

그래서 막연히 책이 오래되서 사라졌나보다 생각했었는데,

알고보니 macos 에서 core 가 다른 형태로 저장되는 거엿음;;

그래서 부랴부랴 리눅스 켜서 확인해봤는데

리눅스도 코어 확인이 안댐 ㅠㅜ


스오플 뒤져보니

/proc/sys/kernel/core_pattern?
/usr/lib/systemd/systemd-coredump?

머시기가 나오더니
코어 파일 저장되는 위치가 고정됫다고 하더군요

책에 따르면 옛날에는 현재 디렉토리에 생성됫엇나 봅니다… 잘 모르니 넘어가고

본론

걍 위에 적힌대로

coredumpctl list 해서 코어 파일 잘 있는지 확인하고

coredumpctl gdb 때리니까 나머지는 책에서 나온대로 잘 되더라구요

bt (backtrace) 누르고 frame 변경해서 어디서 뻑났는지 확인하는 방식 ㅇㅇ;;

http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html

근데 사실 보니까

core 파일 없어도 gdb 에서 bt 치면 잘 뜨더라구요

그러고 보니 core 가 왜 필요하지… 싶었는데

post-moterm debugging 이 가능하다는 말 듣고 무릎을 탁 침

라고 함니다.

우리 모두 reproduce 불가능한 버그 (시간이나 랜덤과 관련된)를 발견하면

코어 덤프를 애용하도록 합시다

아니면 걍 gdb bt ㄱㄱ

잡담

  • gdb 가 좋은 이유:
    일반 디버거에서 mystruct->nodep->data 같은거 확인하려면 fps 를 잘해야 함니다
    왜냐하면 variables 창에서 mystruct 을 찾아서 옆에 화살표를 클릭해서 expand 하고 또 nodep 를 찾아 작은 화살표 눌러서 data 확인 하려면 하세월 걸리기 때문에
    마우스 정밀도 정확도 반응속도가 좋아야 합니다.
    fps 를 잘하면 금상첨화지요.

gdb 에서는 p mystruct->nodep->data 하면 되니까 좋은 거 같음니다
키보드를 많이 치는 대신, fps 재능이 없어도 상관 업음…

흑흑…
부모님은 왜 내가 어릴적에 총게임을 안 시켜 주셧을까… ㅠㅜ


(Deneb) #2

저는 디버깅을 할 때 종종 print문으로 일일이 변수 찍어보곤 하는데, 이런 방법이 있었군요.

확실히 gdb는 익혀놓으면 요긴한 물건인 듯 합니다.


(sh) #3

조아요