gdb 백 트레이스 해석

프로세스에 연결하려면 gdb을 사용했습니다. 왜 무한 루프에 빠졌는지, 그리고 무엇을하는지 알아 내려고 노력 중입니다. 나는 gdb에 명령 backtrace을 발행하고이 결과를 가지고 :gdb 백 트레이스 해석

이

#0 0x000000000041cf30 in [email protected]() 
#1 0x0000000000452320 in winbindd_reinit_after_fork() 
#2 0x00000000004524e6 in fork_domain_child() 
#3 0x0000000000453585 in wb_child_request_trigger() 
#4 0x000000381d2048e2 in tevent_common_loop_immediate() from /lib64/libtevent.so.0 
#5 0x00007fbed6b98e17 in run_events_poll() from /lib64/libsmbconf.so.0 
#6 0x00007fbed6b9922e in s3_event_loop_once() from /lib64/libsmbconf.so.0 
#7 0x000000381d204060 in _tevent_loop_once() from /lib64/libtevent.so.0 
#8 0x000000000042049a in main()

내 질문은 : @ 기호가 첫 번째 줄에 어떤 의미가 있습니까? 나는 _talloc_free이 기능이라는 것을 알고 있지만 @plt은 무엇을 의미합니까? 또한, 두 번째 열의 숫자가 메모리의 함수 주소인지 확인하십시오.

출처

2013-04-10 Dylan Klomparens

필자는'@ plt '가 맹 글링 된 함수 이름의 일부라고 말할 것입니다. (두 번째 열은 호출 사이트의 주소이며, 그 주소에서 분해하면 보게 될 것입니다.) – Jens

나는 "@ plt"가 맹 글링의 일부라는 것을 확신합니다. 그리고 네 번째 열은 귀하의 주소입니다. 이제 "finish"라고 입력하면 gdb가 짧은 순서로 프롬프트로 돌아 가지 않는다면 무한 루프가 talloc에서 무료로 발생하고 있음을 의미합니다. 이것은 talloc 라이브러리 (필자가 사용한 적이없는)의 버그 일 수도 있고, 아마도 힙을 손상시킨 가능성이 있습니다. glibc를 사용할 때 힙 손상을 감지하고 꽤 충돌 메시지를 표시합니다.

valgrind에서 프로그램을 실행하는 것이 좋습니다. 메모리 오류를 신속하게 감지하는 좋은 방법입니다.

출처

2013-04-10 23:06:56

PLT는 절차 연결 표입니다. the documentation here을 참조하십시오. 함수 참조를 게으른 로딩에 사용됩니다.

여기에 항상이 붙어 있습니까? 여기에 확실한 추측이 있습니다. 그렇다면 기능이 해결되지 않았 음을 나타낼 수 있습니다. 예를 들어, 예상 라이브러리가로드되지 않은 경우.

그리고 16 진수는 일반적으로 스택에 푸시 된 명령어 포인터의 값을 나타냅니다. l * <address> 명령을 사용하여이를 확인할 수 있으며, GDB가 그 주소에 코드 줄을 표시하도록 명령합니다. 또는 f <frame#> 명령을 사용하여 해당 스택 프레임으로 전환하십시오.

/proc/<pid>/maps (여기서 <pid>은이 프로세스의 PID 임)을보고 talloc_free이 될 것으로 예상되는 라이브러리가로드되어 있는지 확인하십시오.

출처

2013-04-10 23:12:13 mpontillo

gdb 백 트레이스 해석

답변

관련 문제