c++ - 如何从核心转储文件中识别导致崩溃的完整命令
问题描述
使用 gdb 从核心转储文件中识别完整命令时出现问题崩溃的命令本身可能很长
IE
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.txt -t output/myFile.txt
但是当使用 gdb 来识别“Core was generated by”位置中的命令时</p>
即通过执行
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 文件中获取导致失败的完整命令
提前致谢
解决方案
有没有办法从 coredump 文件中获取导致失败的完整命令
有多种方式,但跑步strings
是错误的方式。
如果您使用调试信息构建程序,您应该能够简单地执行up
命令直到到达main
,然后检查argv[0]
通过argv[argc-1]
。
如果您main
不是使用调试信息构建的,或者它不使用argc
and argv
,您应该能够从__libc_argc
and__libc_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_PRPSINFO
在core
.
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>...}
最后一行实际上是一个谎言——我们知道它'a'
重复了 500 次。
我们可以这样修复它:
(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>}
瞧:我们现在有了完整的命令。
最后,如果您为 GLIBC 安装调试信息,您可以简单地查看__libc_start_main
(称为 your 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
在第 3 帧中,并且可以像 argv
这样检查:
(gdb) fr 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
308 result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
(gdb) p argv[0]@5
$1 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
推荐阅读
- c# - 升级到 2019 社区后,子节点“2”过早退出和 StackOverflowException
- python - 非加权类标签 - 准确性不会改变
- laravel - 在 Laravel 的一个地方为多个路由设置中间件?
- node.js - 如何正确检测中间件中的混合操作
- linux - bash每行打印带有分隔符的连续数字
- pandas - 将文本列转换为二进制,其中一组值 = 1,所有其他值 = 0
- php - 无法在php上打印数组或子数组
- android-recyclerview - Android Studio:将用户添加到 WhatsApp 等群组
- python - TensorFlow 2.0 中的 tf.contrib.layers.recompute_grad 在哪里?
- c# - 重定向到操作并打开新页面