Трассировка отладки GDB без соответствующей информации (#0 0x2e6e6f69 в ?? ())

Я столкнулся с определенной проблемой при отладке с помощью GDB. Мой бинарник генерирует core. Когда я отлаживаю его GDB. Я не получаю соответствующую отладочную информацию.

GDB stack trace (bt):-

[root@ussdgw5 bin]# gdb pull core.11328
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/abc/xyz/bin/pull...done.
[New Thread 11379]
[New Thread 11378]
[New Thread 11377]
[New Thread 11376]
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /opt/septel/lib32/libgctlib.so.1...(no debugging symbols found)...done.
Loaded symbols for /opt/septel/lib32/libgctlib.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `./pull -c /home/abc/xyz/conf/Common.cfg -g /home/abc/xyz/'.
Program terminated with signal 11, Segmentation fault.
#0  0x2e6e6f69 in ?? ()
(gdb) bt
#0  0x2e6e6f69 in ?? ()
#1  0x40310738 in ?? ()
#2  0x20459102 in menu_table ()
#3  0x31073900 in ?? ()
#4  0x35910240 in ?? ()
#5  0x01530084 in ?? ()
#6  0x00000052 in ?? ()
#7  0x00000000 in ?? ()
(gdb) q

bt и bt full не показывают никакой полезной информации. Я выполнил свой двоичный флаг -g. Тот же двоичный файл сгенерировал обычное ядро ​​(ядро с соответствующей информацией об отладке), которое я исправил.

В данном конкретном случае я не могу определить какую-либо проблему. Пожалуйста, предложите, как я могу отладить и решить проблему.


linux coredump segmentation-fault memory-corruption gdb
person user2307143    schedule 22.04.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Приведенные ниже указатели могут помочь вам проверить информацию об отладке -
1. Проверьте, скомпилировали ли вы свой код с включенной информацией об отладке. (например, -g и флаг оптимизации выключен -O(2/3/4/5)) и т. д.
2. Во время генерации ядра проверьте, достаточно ли места в вашей системе. В усеченном файле ядра не будет полной информации для проверки символов.
3. Убедитесь, что среда отладки точно такая же, как среда выполнения (в случае, если обе находятся в другом месте). Неправильная среда также может привести к неизвестным символам.

Это какие-то указатели. Если я вспомню еще несколько, я обновлю ответ. ХТХ!

person kumar_m_kiran    schedule 22.04.2013
comment
@user2307143: Вам помогло? В чем была проблема? Если вы укажете актуальную проблему и решение (и, возможно, проголосуете за соответствующий ответ), это поможет другим участникам прокручивать похожие проблемы. - person kumar_m_kiran; 23.04.2013
comment
Нет. Я использовал флаг -g при компиляции. Я вообще не использовал -O. Я также перепроверил, места было достаточно. Мои среды разработки и производства одинаковы. Первоначально из вашего комментария я подумал, что проблема может быть в пространстве. Но это не так. Я не могу найти решение. Код обращается к одной и той же функции много раз, но каким-то образом он генерирует ошибку сегментации через 3-4 дня, и в ядре нет соответствующей информации, кроме функции menu_table. - person user2307143; 23.04.2013

arrow_upward
0
arrow_downward

gdb pull core.11328

Core was generated by ./ussd_pull_gw ...`

Наиболее вероятной причиной ваших проблем является несовпадение двоичных файлов: возможно, вы анализируете ядро, созданное другим исполняемым файлом.

Вам нужно использовать тот самый исполняемый файл, который создал ядро. Восстановление исполняемого файла, например. -g вместо -O2 приведет к результатам, которые вы наблюдали (но перестроение с -g -O2 часто работает).

person Employed Russian    schedule 22.04.2013
comment
Спасибо. Теперь я использовал правильный двоичный файл. Но все равно результат тот же. Среда отладки и среда разработки одинаковы. Один и тот же двоичный файл используется для создания правильного ядра. Я исправил эти проблемы, но теперь они генерируются без отладочной информации. - person user2307143; 23.04.2013
comment
@user2307143 user2307143 среда отладки и разработки одинаковы - означает ли это, что вы записываете дамп ядра и анализируете его на одном компьютере? но теперь он генерируется без информации об отладке - пожалуйста, обновите свой вопрос; Я сомневаюсь, что вы получаете точно тот же результат, что и раньше. - person Employed Russian; 23.04.2013
comment
Да. Я включил флаг -g на рабочей машине и скомпилировал код на той же машине. Отсутствие отладочной информации означает, что она генерирует отладочную информацию, которой недостаточно для отладки, как вы видите в трассировке, прикрепленной выше. Я вижу только функцию menu_table, а затем несколько шестнадцатеричных адресов. Подскажите пожалуйста в чем может быть дело. - person user2307143; 23.04.2013