2014-07-17 1 views
5

내 프로그램이 올바르게 작동하지 않습니다. 무한 루프 또는 잘못된 뮤텍스 잠금/잠금 해제로 인해 멈춘 것처럼 보입니다. 그러나 나는 버그가 어디 있는지 전혀 모른다. 디버깅을 위해 gdb를 사용해 보았습니다.gdb를 사용하여 프로그램이 멈춘 위치 찾기

중단 점을 지정하지 않았으므로 gdb 백 추적 명령을 사용할 수 없습니다. 오류가 어디에 있는지 전혀 알지 못하기 때문에 지정할 수 없습니다.

gdb에 백 트레이스 용 도구가 "즉시"있습니까?

+10

, 당신은 누를 수'Ctrl 키-C' 디버거에 침입 한 다음 bactrace을 보여, 거기에서 변수 등을 검사합니다. –

+0

'printf'는 디버거를 사용하는 것보다 이상적이지는 않지만 다른 디버깅 방법입니다. –

답변

10

내가 중단 점을 지정하지 않았기 때문에 gdb 백 추적 명령을 사용할 수 없습니다.

예, 가능합니다.

당신이 필요로하는 것은 열등한 (디버깅되는) 프로그램이 어딘가에서 멈추는 것입니다.

처음 프로그램에 연결하면 GDB가 모든 스레드를 중지하고 프로그램이 어디에 있는지 검사 할 수 있습니다. 나중에 Ctrl-C을 누르고 다시 모든 스레드를 볼 수 있습니다. 유용한 명령은 thread apply all where입니다.

-1

당신은 당신이 디버깅 동안 일부 infinte 루프 내부에있는 것을 느낄 때,

중단 점을 가지고 있다면 당신은 아이디어를 얻을 것이다, 코드를 확인하고 바로

가 가능한 루프 후 중단 점을하고 나올려고 그 루프가 끝난 후에도 코드의 해당 부분에서 변수를 변경하거나 gdb에서 샘플 repro를 다시 실행하여

변수를 분석 할 수 있습니다.

7

프로그램의 'ps -ef'에서 프로세스 ID를 가져옵니다. pstack을 사용하여 정확히 걸려있는 기능을 알아야합니다. 실행 스택 추적을 인쇄합니다.

예 출력 : 당신은 당신의 코드가 붙어 생각하면

$ pstack PROCESS_PID 

\#0 0x00000038cfaa664e in waitpid() from /lib64/libc.so.6 
\#1 0x000000000043ed42 in ??() 
\#2 0x000000000043ffbf in wait_for() 
\#3 0x0000000000430bc9 in execute_command_internal() 
\#4 0x0000000000430dbe in execute_command() 
\#5 0x000000000041d526 in reader_loop() 
\#6 0x000000000041ccde in main() 
관련 문제