нет информации о таблице символов, доступной после анализа coredump в gdb

Question

нет информации о таблице символов, доступной после анализа coredump в gdb

0

Я новичок в этом unix и gdb. У меня есть файл coredump, сгенерированный. Я использую gdb для отладки, но нет никакой содержательной информации. Я получаю

(gdb) thread apply all bt full 

Thread 7 (LWP 12190):
#0  0x00007fa2eae29896 in ?? ()
No symbol table info available.
#1  0x000000000000019a in ?? ()
No symbol table info available.
#2  0x00007fa2e9906ce0 in ?? ()
No symbol table info available.

Есть семь семи потоков. и для всех я получаю то же самое. Я не буду продвигаться вперед. Пожалуйста, помогите мне. ИЛИ, пожалуйста, объясните мне, что это значит.

user3913114 08 сен. 2014, в 11:20

Источник

0

возможный дубликат GDB, таблица символов не загружена для основного файла
TartanLlama 08 сен. 2014, в 09:15

Теги:

c++

unix

gdb

1 ответ

Ещё вопросы

возможный дубликат GDB, таблица символов не загружена для основного файла

TartanLlama · Answer 1 · 2014-09-08T06-40-00.000Z

2

Это означает, что для coredump нет таблицы символов. Скорее всего, вы вызывали gdb прямо на coredump, а не как это:

gdb <executable> <coredump>

TartanLlama 08 сен. 2014, в 06:40

0

Благодарю за ваш ответ. Я вызвал GDB непосредственно на coredump. Потому что я не получаю исполняемый файл. Это будет файл coredump, сгенерированный удаленно, который я скопировал и отладил локально.
user3913114 08 сен. 2014, в 09:24
0

Для отладки coredump вам нужен доступ к исполняемому файлу, созданному с помощью символов отладки, в противном случае данные не имеют смысла.
TartanLlama 08 сен. 2014, в 09:29
0

Теперь gdb / opt / bin / core.old.2014 - это команда, которую я дал. Что означает, что я дал исполняемый обряд? даже тогда их значимых данных не найдено. Я все еще получаю ту же ошибку
user3913114 08 сен. 2014, в 09:49
0

/opt/bin/ - это каталог, а не исполняемый файл. Вам нужна программа, из которой был создан дамп.
TartanLlama 08 сен. 2014, в 09:51
0

Нет в этом каталоге только все исполняемые файлы сохраняются. Я работаю над большим кодом, где все двоичные файлы будут сохранены в этом пути. поэтому я дал путь и имя coredump.
user3913114 08 сен. 2014, в 09:54
0

Вам нужно указать непосредственно на программу, из которой был создан coredump, иначе как gdb узнает, где искать символы или как разрешать конфликты имен?
TartanLlama 08 сен. 2014, в 09:56
0

Я дал правильную команду. Но я в конечном итоге в том же выводе. Пожалуйста, расскажите мне, как решить эту проблему. Где не найдена трассировка стека. что я должен сделать, чтобы получить правильную информацию
user3913114 08 сен. 2014, в 10:19
0

Предполагая, что вы сейчас передаете правильный исполняемый файл в gdb, этот исполняемый файл, возможно, не был скомпилирован с символами отладки (-g).
TartanLlama 08 сен. 2014, в 10:24
0

Привет Тартан. По вашему предложению я сделал исполняемый файл скомпилированным с -g. и проверил на coredump. Но я получил тот же результат. Без изменений:(
user3913114 09 сен. 2014, в 04:44
0

Отредактируйте вызовы компилятора и GDB в своем вопросе, что должно дать мне больше информации.
TartanLlama 09 сен. 2014, в 07:50
0

Для того, чтобы беспокоить вас снова. И спасибо за ваш ответ. На самом деле я использую cmake, а затем make, поэтому я проверил файл cmake и увидел, что я также использую флаг -g. Это просто моя неудача, что их нет обратного следа
user3913114 09 сен. 2014, в 11:00
0

Если вы dwarfdump исполняемого файла, вы получаете какие-нибудь символы?
TartanLlama 09 сен. 2014, в 11:01
0

что будет делать dwarfdump? извините, я не знаю. :(
user3913114 09 сен. 2014, в 11:11
0

man dwarfdump
TartanLlama 09 сен. 2014, в 11:12
0

Хорошо. я увижу. спасибо
user3913114 09 сен. 2014, в 11:19

Показать ещё 13 комментариев