無法從gdb backtrace獲取任何信息

Question

我有一個在linux 64位系統下運行的發行版服務器進程。它崩潰並留下一個coredump文件。我使用gdb來調試這樣的：

GDB SVR核心轉儲文件

，得到了以下回溯：

(gdb) where 
#0 0x0000000000432691 in ??() 
#1 0x00002b07655a50cc in ??() 
#2 0x00002b07655a50c4 in ??() 
#3 0x00007fff9fade920 in ??() 
#4 0x0000000000439db3 in ??() 
#5 0x00007fff9fade910 in ??() 
#6 0x00007fff9fade910 in ??() 
#7 0x00007fff9fade8e0 in ??() 
#8 0x00000000004663e2 in ??() 
#9 0x00007fff9fade910 in ??() 
#10 0x00007fff9fade910 in ??() 
#11 0x00007fff9fade930 in ??() 
#12 0x0000000000605108 in ??() 
#13 0x00002b07655a274c in ??() 
#14 0x0000000000ebc678 in ??() 
#15 0x169f49f100000001 in ??() 
#16 0x00000000021dc6c0 in ??() 
#17 0x00002b07655a284c in ??() 
#18 0x00002b07655a27dc in ??() 
#19 0x00007fff9fade960 in ??() 
#20 0x000000000043a03b in ??() 
#21 0x00007fff9fade960 in ??() 
#22 0x0000000000994d02 in ??() 
#23 0x00000000000ecd57 in ??() 
#24 0x00002b07655a274c in ??() 
#25 0x00002b07655a274c in ??() 
#26 0x00002b07655a27dc in ??() 
#27 0x00007fff9fade980 in ??() 
#28 0x000000000060a5eb in ??() 
#29 0x000000009fadeb50 in ??() 
#30 0x00002b07655a274c in ??() 
#31 0x00007fff9fade9d0 in ??() 
#32 0x000000000060a8f0 in ??() 
#33 0x00007fff9fadeb50 in ??() 
#34 0x00007fff9fadea10 in ??() 
#35 0x00002b07655a274c in ??() 
#36 0x00007fff9fadea10 in ??() 
#37 0x000000009fade9d0 in ??() 
#38 0x00007fff9fadeb58 in ??() 
#39 0x0000000000000000 in ??() 

的地址信息無法通過addr2line進行分析，是什麼問題以及如何我可以找到coredump的根源是什麼？

謝謝！

Answer 1

它很難在沒有調試符號的情況下調試程序。在使用應用程序的發行版時，核心轉儲將不包含任何調試信息。

我不確定，但如果您可以將堆棧跟蹤與應用程序的「.map」文件相關聯，那麼您可能會在某處找到它。如果我處於你的位置，我將用調試符號（-g編譯器標誌）重新編譯應用程序，然後繼續調試。

Answer 2

您是否在生成核心轉儲的機器上運行GDB？

爲了GDB正確地重建崩潰堆棧跟蹤，它必須有權訪問確切的在崩潰時使用的二進制文件（或者你得到垃圾）。

實現此目的的最簡單方法是分析生產該機器的機器上的核心。如果這樣做不可行，則必須將所有共享庫複製到例如/tmp/solib-on-server/（保留路徑，所以例如/lib/libc.so.6進入/tmp/solib-on-server/lib/libc.so.6），然後使用GDB set solib-absolute-prefix /tmp/solib-on-server命令加載內核之前的。例如。

gdb -ex 'set solib-absolute-prefix /tmp/solib-on-server' \ 
    -ex 'core /path/to/core' /path/to/executable