Не удается получить информацию из обратной трассировки gdb

У меня есть серверный процесс версии выпуска, работающий в 64-битных системах Linux. Он разбился и оставил файл 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?

Спасибо!


person pixar    schedule 09.08.2011    source источник
comment
Программа скомпилирована с флагом -g? Убедитесь, что вы не удаляете свой исполняемый файл.   -  person Kamath    schedule 09.08.2011


Ответы (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
person Employed Russian    schedule 09.08.2011

Очень сложно отлаживать программы без символов отладки. Поскольку вы используете релизную версию приложения, дамп ядра не будет содержать никакой отладочной информации.

Я не уверен, но если вы можете сопоставить трассировку стека с файлом «.map» вашего приложения, вы можете что-то получить. Если бы я был на вашем месте, я бы перекомпилировал приложение с символами отладки (флаг компилятора -g), а затем продолжил бы отладку.

person Kamath    schedule 09.08.2011