我的程序是这样运行的:

exe -p param1 -i param2 -o param3

它崩溃并生成了一个核心转储文件core.pid。

我想分析一下核心转储文件

gdb ./exe -p param1 -i param2 -o param3 core.pid

但是GDB将EXE文件的参数识别为GDB的输入。

在这种情况下,我如何分析核心转储文件?


当前回答

可执行文件是否有参数并不重要。要在任何具有生成的核心文件的二进制文件上运行GDB,语法如下所示。

Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile

为了更好地理解,让我举下面的例子。

bash-4.1$ **gdb l3_entity 6290-corefile**

**Core was generated** by `/dir1/dir2/dir3/l3_entity **Program terminated with signal SIGABRT, Aborted.**
#0
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
(gdb)

从上面的输出中,您可以猜测一些关于core的信息,无论是NULL访问还是SIGABORT等等。

这些数字#0到#10是GDB的堆栈帧。这些堆栈帧不是二进制的。在上面的0 - 10帧中,如果你怀疑有任何错误,选择该帧

(gdb) frame 8

现在来看看更多的细节:

(gdb) list +

要进一步研究这个问题,您可以在此时打印可疑的变量值。

(gdb) print thread_name

其他回答

稍微不同的方法将允许您完全跳过GDB。如果您想要的只是反向跟踪,linux特定的实用程序'catchsegv'将捕获SIGSEGV并显示反向跟踪。

跳过参数即可。广发银行不需要他们:

gdb ./exe core.pid

来自RMS的GDB调试器教程:

prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...

确保您的文件确实是一个核心映像——使用file检查它。

只需键入命令:

$ gdb <Binary> <codeDump>

Or

$ gdb <binary>

$ gdb) core <coreDump>

不需要提供任何命令行参数。由于前面的练习而生成的代码转储。

我只使用coredumpctl调试(在Fedora 32上),它为我提供了一个GDB控制台来调试我最近的核心转储。