我的程序是这样运行的:
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
其他回答
来自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>
不需要提供任何命令行参数。由于前面的练习而生成的代码转储。
您可以通过多种方式将核心文件与GDB一起使用，但是将要传递给可执行文件的参数传递给GDB并不是使用核心文件的方法。这也可能是你得到错误的原因。您可以通过以下方式使用核心文件:
GDB <可执行> <core-file>或GDB <可执行> -c <core-file>或
gdb <executable>
...
(gdb) core <core-file>
当使用核心文件时，你不需要传递参数。崩溃场景显示在GDB中(在Ubuntu上使用GDB 7.1版本进行了检查)。
例如:
$ ./crash -p param1 -o param2
Segmentation fault (core dumped)
$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2'. <<<<< See this line shows crash scenario
Program terminated with signal 11, Segmentation fault.
#0 __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)
如果您想将参数传递给要在GDB中调试的可执行文件，请使用——args。
例如:
$ gdb --args ./crash -p param1 -o param2
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) r
Starting program: /home/@@@@/crash -p param1 -o param2
Program received signal SIGSEGV, Segmentation fault.
__strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)
手册页将有助于查看其他GDB选项。
最有用的命令是:
bt(回溯) 信息局部变量(显示局部变量值) info寄存器(显示CPU寄存器值) 帧X(改为堆叠帧X) 上下(在堆栈框架中导航(调用链))
简单使用GDB，调试coredump文件:
gdb <executable_path> <coredump_file_path>
“进程”的coredump文件被创建为“核心”。pid”文件。
在你进入GDB提示符后(在执行上面的命令时)，输入:
...
(gdb) where
这将为您提供堆栈的信息，在那里您可以分析崩溃/错误的原因。 其他命令，出于同样的目的是:
...
(gdb) bt full
这和上面一样。按照惯例，它列出了整个堆栈信息(最终导致崩溃的位置)。
稍微不同的方法将允许您完全跳过GDB。如果您想要的只是反向跟踪，linux特定的实用程序'catchsegv'将捕获SIGSEGV并显示反向跟踪。
