c++ - GDB 中没有函数名称的大型核心转储

Question

我对在 Linux 上调试核心转储相当陌生，并且遇到了一个奇怪的问题。希望得到一些建议。

我们在 AWS Linux 机器上运行的游戏服务器偶尔会崩溃。我设置了生成核心转储的盒子。通常，转储大约有几百 MB——大约是内存中程序的大小。我可以将这些加载到 gdb 中，并且似乎获得了有效的回溯。

但我们经常会收到大小为数 GB 的转储。通常，当我在 gdb 中加载这些核心转储时，回溯中没有可用的信息。

这是一个示例输出:

> gdb AAPGOrbis core.3871
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from AAPGOrbis...Reading symbols from <path to>/AAPGOrbis.dbg...done.
done.
[New LWP 3871]
[New LWP 3877]
[New LWP 6557]
[New LWP 3876]
[New LWP 6558]
[New LWP 6559]

warning: Error reading shared library list entry at 0x302e6f732e646165

warning: Error reading shared library list entry at 0x74756d5f64616572
Core was generated by `/opt/aapg/Binaries/Linux/AAPGOrbis aaentry?game=AAGame.AAGamePreGameLobbyDedica'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fed61d001f7 in ?? ()
(gdb) bt full
#0  0x00007fed61d001f7 in ?? ()
No symbol table info available.
#1  0x00007fed61d018e8 in ?? ()
No symbol table info available.
#2  0x0000000000000020 in ?? ()
No symbol table info available.
#3  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)

有什么想法可能导致这种情况吗？我想知道核心转储的大小加上有效数据的缺乏是否表明存在一些非常严重的内存损坏。

任何见解将不胜感激!

Answer 1

warning: Error reading shared library list entry at 0x302e6f732e646165
warning: Error reading shared library list entry at 0x74756d5f64616572

GDB 正在尝试从明显伪造的地址读取已加载共享库的列表(这两个地址都是 ASCII 字符串 ead.so.0read_mut)。

最常见的原因是您向 GDB 提供了错误的二进制文件:您向 GDB 提供的 AAPGOrbis 必须与崩溃的二进制文件完全相同。

另一种可能性是共享库列表(位于堆中)确实已被运行 amok 的程序损坏。