3

只是好奇：当我在 gdb 中加载核心文件时，回溯如下所示：

...

Thread 2 (Thread 1109):
#0  0x2b03d968 in ?? ()

Thread 1 (Thread 23490):
#0  0x2b0c3624 in ?? ()
(gdb)

但是在我使用“文件”加载二进制文件后，我得到了这个：

...

#0  __pthread_cond_wait (cond=0x46b810, mutex=0x46b7f0) at pthread_cond_wait.c:156
#1  0x004076a8 in main (argc=1, argv=0x7fa66784) at idpoint.c:258
...

#0  0x2b0c3624 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x2b0c8464 in *__GI_abort () at abort.c:88
#2  0x2b0faeec in __libc_message (do_abort=2, fmt=0x2b1d0840 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x2b107e3c in malloc_printerr (action=3, str=0x2b1d0930 "free(): invalid next size (fast)", ptr=<value optimized out>) at malloc.c:5994
...

问题：为什么 gdb 甚至不尝试在加载符号之前显示调用堆栈？我的猜测是，它不知道段在内存中的位置，也不知道哪些堆栈数据要解释为数据与地址？它是否正确？

如果有可能获得 gdb:s 最好的尝试来显示没有符号的调用堆栈、了解堆栈深度或供以后解释，那就太好了……

4

1 回答 1

3

因为二进制文件包含允许调试器理解的符号信息（调试符号），例如，每个函数的堆栈帧有多大[在函数中的任何给定时间也是如此！]。此信息在代码启动时不会加载到内存中，因此无法将其保存在core文件中。

你当然可以使用x/200 $esp（或者任何调用堆栈指针的东西——我猜是x86——如果它是ARM，那么它是$R15从内存中调用的）。不幸的是，如果无法访问符号，gdb就不会真正知道堆栈上是什么，并且只能提供堆栈的原始转储 - 在大多数情况下，这甚至比不显示任何内容更有帮助，因为显示大量随机数据（并且大部分堆栈将是 - 特别是如果帧指针被关闭 - 使用帧指针你有一些机会取消嵌套堆栈）在大多数情况下是非常无用的。

于 2013-02-14T11:31:27.177 回答