Question

我正在分析这个核心转储

   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 ?? ()

我无法知道哪个函数??映射到OR，例如#10 0x08061402 in ?? () 落在哪个地址范围......

请帮我调试一下。

Answer 1

您的程序没有调试符号。用-g重新编译它。确保您没有删除可执行文件，例如将-s传递给链接器。

Answer 2

尽管@ user794080没有这么说，但他的程序很可能是一个32位的Linux可执行文件。

有两个可能的原因（我可以想到）来自主可执行文件的符号（并且[0x08040000,0x08100000] 中的堆栈跟踪中的所有符号都是来自主可执行文件的）不是出现。

主要的可执行文件实际上已被剥离（这与 ninjalj的答案），并且经常在'-s'被传递到链接器时发生，可能是无意中发生的。
可执行文件已经使用新的（呃）GCC进行编译，但是正在由旧的（呃）GDB进行调试，这会在一些较新的矮人构造上窒息（GDB应该会发出警告）。

Answer 3

要知道哪些库映射到应用程序，记录一个程序的pid，在gdb中停止并在其他控制台中运行

cat /proc/$pid/maps

wher $ pid是已停止进程的pid。地图文件的格式在http://linux.die.net/man/5/proc描述 - 从“/ proc / [number] / maps开始包含当前映射的内存区域及其访问权限的文件。“

此外，如果您的操作系统不使用ASLR（地址空间布局随机化）或者您的程序已禁用，则可以使用

ldd ./program

列出链接库及其内存范围。但是如果打开ASLR，您将无法获得真实的内存映射范围信息，因为它将针对每个程序运行进行更改。但即使这样，你也会知道，动态链接了哪些库，并为它们安装了一个debuginfo。

Answer 4

堆栈可能已损坏。 “??”如果堆栈上的返回地址被覆盖，例如缓冲区溢出，则会发生这种情况。

gdb：地址范围映射

4 个答案: