2011-04-29 4 views
4

GDB를 사용하여 C 프로그램을 디버깅했지만 GDB가 일부 코드를 두 번 실행합니다. 예를 들어GDB 디버깅 문제

,

.... 
    stream_t *s = stream_CommonNew(VLC_OBJECT(p_access)); 
    stream_sys_t *p_sys; 
    if(!s) 
    return NULL; 
    s->p_input = p_access->p_input; 
    s->psz_path = strdup(p_access->psz_path); 
    .... 

GDB 디버깅,

292  stream_t *s = stream_CommonNew(VLC_OBJECT(p_access)); 
Missing separate debuginfos, use: debuginfo-install dbus-libs-1.2.16-9.fc12.i686 libcap-ng-0.6.2-3.fc12.i686 
(gdb) next 
295  if(!s) 
(gdb) 
292  stream_t *s = stream_CommonNew(VLC_OBJECT(p_access)); 
(gdb) 
295  if(!s) 
(gdb) 
298  s->p_input = p_access->p_input; 
(gdb) 
299  s->psz_path = strdup(p_access->psz_path); 
(gdb) 
298  s->p_input = p_access->p_input; 
(gdb) 
299  s->psz_path = strdup(p_access->psz_path); 

나는 혼란 스러워요. 이유를 설명해 주시겠습니까?

감사

+2

컴파일러 최적화가 활성화되어 있습니까? –

+0

@Oli Charlesworth : 예, 가능하다고 생각합니다. – JavaMobile

답변

4

실제로 동일한 코드를 두 번 실행하지 않습니다. 컴파일러 최적화로 인해 기계 명령어가 재정렬되어 두 번째 소스 라인에 대해 생성 된 일부 명령어가 첫 번째 소스 라인의 마지막 명령어 앞에 배치 될 수 있습니다. Gdb의 "next"명령은 명령에 해당하는 소스 라인이 변경 될 때 중지됩니다. 실제로는 아직 완료되지 않은 나머지 소스 행을 실제로 실행 중일 수 있습니다.

+0

알겠습니다. 그렇다면 프로그램의 실행 상태를 어떻게 알 수 있습니까? – JavaMobile

+0

문제가 발생하면 Pih가 제안한대로 최적화하지 않고 컴파일 할 수 있습니다. 실제 최적화에 관심이 있다면 항상 소스 코드 ('nexti','stepi') 대신 코드를 분해하고 기계 명령어로 단계를 밟을 수 있습니다. – mark4o

1

한번에 모든 최적화 (-O0)없이 컴파일하고 다시 실행합니다. 또 다른 아이디어는 s-> p_input에 감시를 두어이 구조 필드가 두 번 수정되었는지 확인하는 것입니다.

+0

Worked? 문제는 무엇 이었습니까? – Pih

+0

이유는 컴파일러 최적화라고 생각합니다. 그래서 저는 그냥 'g ++ -o0'을 사용하여 이것을 끕니다. – JavaMobile