C++ 如何从核心转储文件中识别导致崩溃的完整命令

使用gdb从核心转储文件识别完整命令时出现问题 崩溃的命令本身可能很长

i、 e

但是当使用gdb识别“Core是由生成的”位置中的命令时

i、 e.通过执行

gdb -c core.56536

输出：

GNU gdb (GDB) Red Hat Enterprise Linux 7.10-20.el7

….

Core was generated by `myCommand -f log/SlaRunTimeReport.rep -I 
input/myFile.t'.

myCommand 

myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t

可以看到完整的命令（可执行文件+参数）被剪切在中间

‘myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t'

另外，使用字符串命令也无助于识别完整的命令

strings core.56536 | grep PMRunTimeReport

输出：

GNU gdb (GDB) Red Hat Enterprise Linux 7.10-20.el7

….

Core was generated by `myCommand -f log/SlaRunTimeReport.rep -I 
input/myFile.t'.

myCommand 

myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t

有没有办法从coredump文件中获取导致故障的完整命令

提前谢谢

有没有办法从coredump文件中获取导致故障的完整命令

有多种方法，但运行

字符串
是错误的方法

如果使用调试信息构建程序，您应该能够简单地执行
up
命令，直到到达
main
，然后通过
argv[argc-1]
检查
argv[0]

如果您的
main
不是使用调试信息构建的，或者如果它没有使用
argc
和
argv
，您应该能够从
libc\u argc
和
libc\u argv
变量恢复该信息。例如：

$ ./a.out foo bar baz $(python -c 'print "a" * 500')
Aborted (core dumped)

$ gdb -q ./a.out core
Core was generated by `./a.out foo bar baz aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.

请注意，“生成者”被截断——它来自
struct prpsinfo
内部的固定长度数组，保存在
NT\u prpsinfo
ELF Note中的
核心
中

Program terminated with signal SIGABRT, Aborted.
#0  0x00007fab38cfcf2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-15.fc28.x86_64

(gdb) p (int)__libc_argc
$1 = 5
(gdb) p ((char**)__libc_argv)[0]@5
$2 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
  0x7ffede4328af "baz", 
  0x7ffede4328b3 'a' <repeats 200 times>...}

瞧，我们现在有了完整的命令

最后，如果为GLIBC安装调试信息，只需查看
\uu libc\u start\u main
（称为
main
）：

有没有办法从coredump文件中获取导致故障的完整命令

有多种方法，但运行
字符串
是错误的方法

如果使用调试信息构建程序，您应该能够简单地执行
up
命令，直到到达
main
，然后通过
argv[argc-1]
检查
argv[0]

如果您的
main
不是使用调试信息构建的，或者如果它没有使用
argc
和
argv
，您应该能够从
libc\u argc
和
libc\u argv
变量恢复该信息。例如：

$ ./a.out foo bar baz $(python -c 'print "a" * 500')
Aborted (core dumped)

$ gdb -q ./a.out core
Core was generated by `./a.out foo bar baz aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.

请注意，“生成者”被截断——它来自
struct prpsinfo
内部的固定长度数组，保存在
NT\u prpsinfo
ELF Note中的
核心
中

Program terminated with signal SIGABRT, Aborted.
#0  0x00007fab38cfcf2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-15.fc28.x86_64

(gdb) p (int)__libc_argc
$1 = 5
(gdb) p ((char**)__libc_argv)[0]@5
$2 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
  0x7ffede4328af "baz", 
  0x7ffede4328b3 'a' <repeats 200 times>...}

瞧，我们现在有了完整的命令

最后，如果为GLIBC安装调试信息，只需查看
\uu libc\u start\u main
（称为
main
）：

您不能在包含
main（）
的堆栈框架中打印
argv
的内容吗？请尝试正确设置问题的格式。我将提供非常短的文件名，以避免输出中的长度限制。如果只有长的参数引起麻烦，这就暗示了你的bug。这可能是一个存储覆盖的症状，覆盖了ARGV列表的一部分。为了证明，请在程序开始时打印argv参数列表的内容。。。然后当它转储时，检查GDB是否显示与程序开始时打印的值相同的值。。。。如果没有，则您知道发生了存储覆盖。希望您已经使用了valgrind。难道您不能在包含
main（）
的堆栈框架中打印
argv
的内容吗？请尝试正确设置问题的格式。我将提供非常短的文件名，以规避输出中的长度限制。如果只有长的参数引起麻烦，这就暗示了你的bug。这可能是一个存储覆盖的症状，覆盖了ARGV列表的一部分。为了证明，请在程序开始时打印argv参数列表的内容。。。然后当它转储时，检查GDB是否显示与程序开始时打印的值相同的值。。。。如果没有，则您知道发生了存储覆盖。希望您已经使用了valgrind。我曾尝试运行：gdb-q./myCommand-c core.56590，然后：p（int）\u libc\u argc结果是：$1=7，然后运行下一个：set print elem 0，然后：p（（char**）\u libc\u argv）[0]@7未成功，Get:无法访问地址0x3003ff68I处的内存我也尝试了其他建议，但我假设我没有glibc的调试信息，我运行：set backtrace pass main，然后我运行：bt然后我查找u libc_start_main并在我的例子中运行：fr 2，但在我得到的输出中没有argc:#2 0x00007fbda6d46b35 in u libc_start_main（）**from/lib64/libc.6，然后我运行：p argc**并得到：*当前上下文中没有符号“argc”。@AlexOstar“我没有glibc的调试信息”是一个可以解决的问题：安装它。我曾尝试运行：gdb-q./myCommand-c core.56590，然后：p（int）\uuu libc\u argc结果是：$1=7，然后运行下一个：set print elem 0，然后：p（（char**）\uu libc\u argv）[0]@7未成功，Get:无法访问地址0x3003ff68I处的内存我也尝试了其他建议，但我假设我没有glibc的调试信息，我运行：set backtrace pass main，然后我运行：bt然后我查找u libc_start_main并在我的例子中运行：fr 2，但在我得到的输出中没有argc:#2 0x00007fbda6d46b35 in u libc_start_main（）**from/lib64/libc.6，然后我运行：p argc**并得到：*当前上下文中没有符号“argc”。@AlexOstar“我没有glibc的调试信息”是一个可以解决的问题：安装它。