GDB: сопоставления диапазона адресов - PullRequest
0 голосов
/ 11 июня 2011

Я анализирую этот дамп ядра

   Program received signal SIGABRT, Aborted.
    0xb7fff424 in __kernel_vsyscall ()
    (gdb) where
    #0  0xb7fff424 in __kernel_vsyscall ()
    #1  0x0050cd71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
    #2  0x0050e64a in abort () at abort.c:92
    #3  0x08083b3b in ?? ()
    #4  0x08095461 in ?? ()
    #5  0x0808bdea in ?? ()
    #6  0x0808c4e2 in ?? ()
    #7  0x080b683b in ?? ()
    #8  0x0805d845 in ?? ()
    #9  0x08083eb6 in ?? ()
    #10 0x08061402 in ?? ()
    #11 0x004f8cc6 in __libc_start_main (main=0x805f390, argc=15, ubp_av=0xbfffef64, init=0x825e220, fini=0x825e210, 
        rtld_fini=0x4cb220 <_dl_fini>, stack_end=0xbfffef5c) at libc-start.c:226
    #12 0x0804e5d1 in ?? ()

Я не могу знать, какая функция ?? отображается на ИЛИ, например, #10 0x08061402 in ?? () попадает в какой диапазон адресов ...

Пожалуйста, помогите мне отладить это.

Ответы [ 4 ]

2 голосов
/ 11 июня 2011

Несмотря на то, что @ user794080 не сказал об этом, представляется весьма вероятным, что его программа является 32-разрядным исполняемым файлом linux.

Есть две возможные причины (я могу думать) символов из основного исполняемого файла (и все символы в трассировке стека в диапазоне [0x08040000,0x08100000) равны из основного исполняемого файла), чтобы не показывать до.

  1. Основной исполняемый файл фактически удален (это так же, как ответ ниндзяля), и часто случается, когда в компоновщик передается '-s', возможно, случайно.
  2. Исполняемый файл был скомпилирован с новым (er) GCC, но отлаживается старой (er) GDB, которая блокирует некоторую более новую конструкцию дварфа (об этом должно быть предупреждение от GDB).
2 голосов
/ 11 июня 2011

В вашей программе нет символов отладки.Перекомпилируйте это с -g.Убедитесь, что вы не удалили свой исполняемый файл, например, передав -s компоновщику.

0 голосов
/ 12 июня 2011

Стек может быть поврежден."??"может произойти, если адрес возврата в стеке был переписан, например, переполнением буфера.

0 голосов
/ 11 июня 2011

Чтобы узнать, какие библиотеки отображаются в приложении, запишите pid вашей программы, остановитесь в gdb и запустите в другой консоли

cat /proc/$pid/maps

wher $ pid - это pid остановленного процесса. Формат файла карт описан в http://linux.die.net/man/5/proc - начиная с "/ proc / [число] / maps Файл, содержащий отображенные в настоящий момент области памяти и их права доступа. "

Кроме того, если ваша ОС не использует ASLR (рандомизацию адресного пространства) или она отключена для вашей программы, вы можете использовать

ldd ./program

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

...