Отладка C ++ из основных файлов с помощью GDB - PullRequest
1 голос
/ 29 октября 2009

GDB, кажется, всегда работает только для программ на C, но для C ++ я часто получаю следующие загадочные стеки:

(gdb) bt
#0  0x08055fa4 in std::runtime_error::what ()
#1  0x080576c8 in std::runtime_error::what ()
#2  0x08057dda in std::runtime_error::what ()
#3  0x080580d2 in std::runtime_error::what ()
#4  0x08058662 in std::runtime_error::what ()
#5  0x08058725 in std::runtime_error::what ()
#6  0x0806ef7a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<char*> ()
#7  0x00c0adec in __libc_start_main () from /lib/libc.so.6
#8  0x0804d011 in std::runtime_error::what ()

Которые на поверхности не дают абсолютно никаких подсказок относительно того, где возникла проблема. Есть ли способ получить больше информации из такого файла ядра или сделать дамп программы более полезным?

Ответы [ 3 ]

5 голосов
/ 29 октября 2009

Маловероятно, что текст для std::runtime_error::what() на самом деле охватывает диапазон от 0x0804d011 до 0x08058725, как предполагает обратная трассировка. Это будет более 45 КБ кода.

Скорее всего, код поиска символов, который пытается разрешить 0x08055fa4, 0x080576c8 и т. Д., Просто находит std::runtime_error::what() как последний используемый символ перед этими адресами, что часто является результатом удаления исполняемого файла (когда вы сделали, передав -s переключатель на компоновщик).

Я бы сосредоточился на кадре стека # 6. Поскольку это ctor для довольно простого класса, моя SWAG будет заключаться в том, что вы передали NULL-указатель или указатель на строку, не заканчивающуюся NULL.

EDIT: обратите внимание, что если вы просто перестроите исполняемый файл из точно таких же источников без ключа -s, вы получите гораздо более пригодный для использования стек из GDB, используя уже существующий файл core. Нет необходимости ждать, пока вновь созданный исполняемый файл снова выдаст core.

2 голосов
/ 29 октября 2009

Я все время использую GDB для C ++, и обычно у меня нет проблем с возвратом стека, при условии, конечно, что стек не был разбит каким-либо переполнением буфера.

Нет ничего принципиально отличного в трассировке стека в программе на C ++ по сравнению с программой на C, которая затруднит вам интерпретацию трассировки. Вы уверены, что:

А) ваша программа как-то не разбивает стек?
Б) вы компилируете с флагом -g?

0 голосов
/ 29 октября 2009

Сначала убедитесь, что вы установили -pg -ggdb флаги компилятора:

g++ -pg -ggdb prog.cpp -o prog

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

Чтобы проверить файл ядра, используйте это:

gdb -quiet -se=prog -c prog.core

Это всегда должно давать достаточно информации для устранения проблем с дампами ядра:)
Ура!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...