How to identify the full command that caused the crash from the core dump file

Question

There is a problem to identify the full command from the core dump file using gdb The crashed command itself can be long

i.e.

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

But When using gdb to identify the command in the location “Core was generated by”

i.e. by executing

gdb -c core.56536

The Output:

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

….

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

It is possible to see that the full command(executable + parameters) was cut in the middle

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

In additional using strings command , also did not help to identify the full command

strings core.56536 | grep PMRunTimeReport

The Output:

myCommand 

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

Is there any way to get from coredump file the full command that caused the failure

Thanks in Advance

Answer 1

Is there any way to get from coredump file the full command that caused the failure

There are multiple ways, but running strings is the wrong way.

IF you built your program with debug info, you should be able to simply execute up command until you reach main, then examine argv[0] through argv[argc-1].

If your main was not built with debug info, or if it doesn't use argc and argv, you should be able to recover that info from __libc_argc and __libc_argv variables. Example:

$ ./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'.

Note that the "generated by" is truncated -- it comes from a fixed length array inside of struct prpsinfo, saved in NT_PRPSINFO ELF note in the 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>...}

This last line is actually a lie -- we know that 'a' repeats 500 times.

We can fix it like so:

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

Voila: we now have the complete command.

Lastly, if you install debug info for GLIBC, you can simply look in the __libc_start_main (which called 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 ()

Here you can clearly see argc and argv in frame 3, and can examine that argv like so:

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