解釋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'是mangled函數名稱的一部分。（我認爲第二列是呼叫站點的地址;在該地址進行反彙編，您將看到。） – Jens 2013-04-10 21:42:26

我很確定「@plt」是名稱的一部分。是的，第二列是你的地址。所以你現在可以輸入「finish」，如果gdb沒有讓你回到短時間的提示，那麼這意味着你的無限循環發生在toloc的free中。這可能是talloc庫中的一個bug（我從來沒有用過），或者更可能是你損壞了你的堆。你經常會發現，當使用glibc時，它會檢測到堆損壞並給你一個漂亮的崩潰消息。

我會建議你在valgrind中運行你的程序 - 這是快速檢測內存錯誤的好方法。

來源

2013-04-10 23:06:56

PLT是程序連接表。請參閱the documentation here。這用於延遲加載函數引用。

是不是總是卡在這裏？這裏是純粹的猜想，但如果是這樣的話，那可能表明這個功能仍然沒有解決。例如，如果預期的庫未加載。

是的，十六進制數字通常表示指令指針推入堆棧的值。您可以使用l * <address>命令驗證這一點，以告知GDB列出該地址的代碼行。或者使用f <frame#>命令切換到該堆棧幀。

試試看/proc/<pid>/maps（其中<pid>是此過程的PID），並查看您希望加載的文件庫是否爲talloc_free。

來源

2013-04-10 23:12:13 mpontillo

回答

相關問題