테스트 케이스로 치명적인 오류가 발생하는 프로그램이 있는데, 로그와 스택 추적을 치명적으로 읽음으로써 문제를 찾을 수 있습니다. 읽기 작업이 있음이 밝혀졌습니다 NULL 포인터시.gdb로 실행할 때 치명적인 오류가 사라졌습니다.
그러나 gdb를 첨부하여 의심스러운 코드 주위에 중단 점을 설정하려고하면 null 포인터가 관찰되지 않습니다! 이 프로그램은 오류없이 원활하게 작동합니다.
이것은 단일 프로세스, 단일 스레드 프로그램이므로 이전에 이런 종류의 문제가 발생하지 않았습니다. 아무도 내게 몇 가지 의견을 줄 수 있습니까? 감사.
추가 : 치명적인 트리거 코드 앞에 pause() syscall을 호출하여 치명적인 오류가 발생하기 전에 프로그램을 잠자기 상태로 만든 다음 gdb를 on-the-fly에 첨부해야합니다. 슬프게도 치명적인 오류는 발생하지 않았습니다. .
그것은 코드를 보지 않고 단지 추측이지만, 디버거 가끔이 할 : 당신이
내가 돈 특정 물건을 초기화를 ' GDB에 대한 견적을 가지고 있지만, 나는 valgrind에 하나를 가지고있다. (부여 된 두 가지가 이다.) 프로그램이 Valgrind의에서 실행하면My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?
는 환경은 기본적으로 실행시에 약간 다릅니다. 예를 들어, 메모리 레이아웃이 다르며 스레드 예약 방식은 입니다.
동일한 GDB에 갈 것입니다.
는 대부분의 시간이 어떤 차이를하지 않지만, 프로그램이 버그가 특히 경우, 할 수있다.
그래서 실제 문제가 프로그램에 있습니다.
포인터에서 유효하지 않은 읽기 인 경우 예기치 않은 동작이 발생할 수 있습니다. 당신은 이미 무엇이 잘못을 일으키는 지 알기 때문에 최대한 빨리 제거해야합니다. 일반적으로 잘못된 포인터 작업을 처리 할 때 예기치 않은 상황이 발생할 것으로 예상하십시오.
여러 가지 일이 발생할 수 있습니다. 응용 프로그램의 타이밍을 변경할 수 있으므로 다중 스레드 응용 프로그램의 경우 예를 들어 준비 플래그를 먼저 설정 한 다음 버퍼없이 데이터를 버퍼에 복사 할 수 있습니다 다른 스레드가 연결된 디버거는 버퍼가 채워지거나 일부 포인터가 설정되기 전에 버퍼에 액세스 할 수 있습니다.
일부 응용 프로그램에는 디버깅 방지 기능이있을 수도 있습니다. 어쩌면 코드 조각은 디버거 내부에서 실행될 때 절대 건드리지 않을 것입니다.
분석 방법 중 하나는 코어 덤프입니다.당신이 ulimit -c unlimited으로 만들 수있는 다음 응용 프로그램을 시작하고 코어 덤프 때 당신은 여기에 유용한 쓰기를 업 찾을 수 있습니다 gdb ./application ./core와 GDB에로드 수 :`valgrind` /`memcheck`와 http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php
시도 디버깅을? –
ahh, Heisenberg 's Uncertainty Principle, 프로그래밍에 적용됨 –
악명 높은 [heisenbug] (http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug) –