gdb(1) 对基于“-g”的核心文件的无用堆栈跟踪：只有“... in ?? ()”

Question

我从 gdb 得到以下（无用的）堆栈跟踪：

$ gdb -e pqact -c core.6067
GNU gdb (GDB) Fedora (7.2-52.fc14)
Copyright (C) 2010 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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
[New Thread 6067]
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Cannot access memory at address 0x675
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Cannot access memory at address 0x675
Core was generated by `pqact -f WMO|CONDUIT|NGRID|EXP /local/ldm/etc/GEMPAK/pqact.gempak_upc'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000003790044d99 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.x86_64
(gdb) where
#0  0x0000003790044d99 in ?? ()
#1  0x00000000903959a0 in ?? ()
#2  0x00000000900466e4 in ?? ()
#3  0x000000379080ee20 in ?? ()
#4  0x000000000040f81e in ?? ()
#5  0x000000379080ee60 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) ^Z

程序是在启用调试的情况下构建的（libtool 为清楚起见省略了样板文件）：

$ c99 ...  -g ... -c -o action.o action.c
$ c99 ...  -g ... -c -o filel.o filel.c
$ c99 ...  -g ... -c -o palt.o palt.c
$ c99 ...  -g ... -c -o pbuf.o pbuf.c
$ c99 ...  -g ... -c -o pqact.o pqact.c 
$ c99 ...  -g ... -c -o state.o state.c 
$ c99 -g -o pqact action.o filel.o palt.o pbuf.o pqact.o state.o ...

c99 在我的系统上是 gcc：

$ uname -a
Linux xxx.xxx.xxx.xxx 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
$ type c99
c99 is /usr/bin/c99
$ c99 -dumpversion
4.5.1

生成的程序和核心文件显示正常：

$ file pqact
pqact: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
$ file core.6067
core.6067: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'pqact -f WMO|CONDUIT|NGRID|EXP /local/ldm/etc/GEMPAK/pqact.gempak_upc'
$ ldd pqact
linux-vdso.so.1 =>  (0x00007fff385ff000)
libldm.so.0 => /opt/ldm/ldm-6.13.0.0/lib/libldm.so.0 (0x00007ffcb2f3a000)
libgdbm.so.3 => /usr/lib64/libgdbm.so.3 (0x0000003790400000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00000030d8a00000)
libz.so.1 => /lib64/libz.so.1 (0x0000003d27e00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003791800000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffcb2c8c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003790800000)
libc.so.6 => /lib64/libc.so.6 (0x0000003790000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003790c00000)
/lib64/ld-linux-x86-64.so.2 (0x000000378fc00000)

知道为什么堆栈跟踪没用吗？

Answer 1

Any ideas why the stack-trace is useless?

最常见的原因是您提供给 GDB 用于分析内核的二进制文件与生成内核时使用的二进制文件不匹配。

例如，如果您优化的二进制文件崩溃并生成核心，然后您在没有优化的情况下重建该二进制文件，并尝试使用新的二进制文件来分析现有核心，那是行不通的。

使用较新版本更新系统库也会产生这种效果。将核心从一台机器复制到另一台机器也是如此（除非系统库匹配）。

另见 this answer。

gdb(1) 对基于“-g”的核心文件的无用堆栈跟踪：只有“... in ?? ()”

Useless stack trace by gdb(1) of "-g"-based core-file: nothing but "... in ?? ()"

c

debugging

gdb

stack-trace