Linux 当有命令行参数时，如何使用 GDB 分析程序的核心转储文件？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8305866/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I analyze a program's core dump file with GDB when it has command-line parameters?
提问by Treper
My program operates like this:
我的程序是这样运行的：
exe -p param1 -i param2 -o param3
It crashed and generated a core dump file, core.pid.
它崩溃并生成了一个核心转储文件core.pid.
I want to analyze the core dump file by
我想通过以下方式分析核心转储文件
gdb ./exe -p param1 -i param2 -o param3 core.pid
But GDB recognizes the parameters of the EXE file as GDB's input.
但是 GDB 将 EXE 文件的参数识别为 GDB 的输入。
How do I analyze a core dump file in this situation?
在这种情况下如何分析核心转储文件？
采纳答案by another.anon.coward
You can use the core with GDB in many ways, but passing parameters which is to be passed to the executable to GDB is not the way to use the core file. This could also be the reason you got that error. You can use the core file in the following ways:
您可以通过多种方式将核心与 GDB 一起使用，但是将要传递给可执行文件的参数传递给 GDB 并不是使用核心文件的方式。这也可能是您收到该错误的原因。您可以通过以下方式使用核心文件：
gdb <executable> <core-file>or gdb <executable> -c <core-file>or
gdb <executable> <core-file>或gdb <executable> -c <core-file>或
gdb <executable>
...
(gdb) core <core-file>
When using the core file you don't have to pass arguments. The crash scenario is shown in GDB (checked with GDB version 7.1 on Ubuntu).
使用核心文件时，您不必传递参数。崩溃场景显示在 GDB 中（在 Ubuntu 上使用 GDB 7.1 版进行检查）。
For example:
例如：
$ ./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)
If you want to pass parameters to the executable to be debugged in GDB, use --args.
如果要将参数传递给要在 GDB 中调试的可执行文件，请使用--args.
For example:
例如：
$ 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)
Man pages will be helpful to see other GDB options.
手册页将有助于查看其他 GDB 选项。
回答by Nialscorva
Just skip the parameters. GDB doesn't need them:
直接跳过参数。GDB 不需要它们：
gdb ./exe core.pid
回答by Brian Cain
From RMS's GDB debugger tutorial:
prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...
Make sure your file really is a coreimage -- check it using file.
确保您的文件确实是一个core图像——使用file.
回答by Ranjithkumar T
You can analyze the core dump file using the "gdb" command.
您可以使用“gdb”命令分析核心转储文件。
gdb - The GNU Debugger
syntax:
# gdb executable-file core-file
example: # gdb out.txt core.xxx
回答by parasrish
Simple usage of GDB, to debug coredump files:
GDB的简单用法，调试coredump文件：
gdb <executable_path> <coredump_file_path>
A coredump file for a "process" gets created as a "core.pid" file.
“进程”的核心转储文件被创建为“core.pid”文件。
After you get inside the GDB prompt (on execution of the above command), type:
进入 GDB 提示符后（在执行上述命令时），键入：
...
(gdb) where
This will get you with the information, of the stack, where you can analayze the cause of the crash/fault. Other command,for the same purposes is:
这将为您提供堆栈信息，您可以在其中分析崩溃/故障的原因。 出于相同目的的其他命令是：
...
(gdb) bt full
This is the same as above. By convention, it lists the whole stack information (which ultimately leads to the crash location).
这与上述相同。按照惯例，它会列出整个堆栈信息（最终会导致崩溃位置）。
回答by Rob Latham
A slightly different approach will allow you to skip GDB entirely. If all you want is a backtrace, the Linux-specific utility 'catchsegv'will catch SIGSEGV and display a backtrace.
稍微不同的方法将允许您完全跳过 GDB。如果您只需要回溯，Linux 特定的实用程序“catchsegv”将捕获 SIGSEGV 并显示回溯。
回答by KB Arora
Simply type the command:
只需键入命令：
$ gdb <Binary> <codeDump>
Or
或者
$ gdb <binary>
$ gdb) core <coreDump>
There isn't any need to provide any command line argument. The code dump generated due to an earlier exercise.
不需要提供任何命令行参数。由于先前的练习而生成的代码转储。
回答by Venkatakrishna Kalepalli
It doesn't matter if the executable has arguments or not. To run GDB on any binary with a generated core file, the syntax is below.
可执行文件是否有参数并不重要。要使用生成的核心文件在任何二进制文件上运行 GDB，语法如下。
Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile
Let me take the below example for more understanding.
让我以下面的例子来加深理解。
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)
From the above output, you can guess something about core, whether it is a NULL access, SIGABORT, etc..
从上面的输出，你可以猜到一些关于core的东西，是否是NULL访问，SIGABORT等等。
These numbers #0 to #10 are the stack frames of GDB. These stack frames are not of your binary. In the above 0 - 10 frames if you suspect anything wrong select that frame
这些数字#0 到#10 是 GDB 的堆栈帧。这些堆栈帧不是您的二进制文件。在上面的 0 - 10 帧中，如果您怀疑有任何错误，请选择该帧
(gdb) frame 8
Now to see more details about it:
现在查看有关它的更多详细信息：
(gdb) list +
To investigate the issue further, you can print the suspected variable values here at this point in time.
要进一步调查该问题，您可以在此时在此处打印可疑的变量值。
(gdb) print thread_name
