Question

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

即

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

但是当使用gdb来识别“Core is generated by”

这个位置的命令时

即。通过执行

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 -f log/SlaRunTimeReport.rep -I input/myFile.t'

另外使用 strings 命令，也无法识别完整命令

strings core.56536 | grep PMRunTimeReport

输出：

myCommand 

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

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

先谢谢

Answer 1

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

有多种方法，但运行strings是错误的方式。

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

如果您的main未使用调试信息构建，或者它没有使用argc和argv，那么您应该能够从{{1}恢复该信息}和__libc_argc个变量。例如：

__libc_argv

请注意＆＃34;由＆＃34;生成被截断 - 它来自$ ./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的{{1}} ELF注释中。

NT_PRPSINFO

这最后一行实际上是谎言 - 我们知道core重复了500次。

我们可以这样修理：

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>...}

Voila：我们现在有了完整的命令。

最后，如果您为GLIBC安装调试信息，您只需查看'a'（称为(gdb) set print elem 0 (gdb) p ((char**)__libc_argv)[0]@5 $3 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar", 0x7ffede4328af "baz", 0x7ffede4328b3 'a' <repeats 500 times>}）：

__libc_start_main

在这里，您可以清楚地看到第3帧中的main和(gdb) set backtrace past-main (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fab38ce7561 in __GI_abort () at abort.c:79 #2 0x00000000004004ef in main () at foo.c:3 #3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108) at ../csu/libc-start.c:308 #4 0x000000000040042a in _start ()，并且可以像这样检查 argc：

argv

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

1 个答案: