3

A program I am working on is crashing and generating core dumps. I think that the issue is related to the arguments that it's being called with, some of which are automatically generated by another (rather complicated) program. So I've tried using gdb to debug, or file core.MyApplication.1234 to get the arguments.

However, the command is pretty lengthy, and the output looks something like:

core.MyApplication.1234: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './MyApplication -view -mwip localhost -mwnp 12345 -mwlp 12346 -mwti 12347 -Debu'

(I did change the names for this example, but you get the idea.)

I know for a fact that there were several more arguments after this, but in the core files the command is always truncated at 80 characters. Both gdb and file report this. Looking at the output of objdump I'm not sure the rest was even written into the core dump, because it appears to cut off after "-Debu" too.

I am running this on RHEL6. I found this thread from 2007 describing a solution for Solaris systems using pargs, but that's not a valid command on my system, and the Red Hat "equivalents" I've found only work on running processes, not a core file.

How can I recover the entire command used to run the program? Is that even possible?

5

The data is there (at least up to 999 entries totalling at least 6885 bytes of numbered blahs):

> cat segfault.c 
int main(int argc, char *argv[])
{
    char *s = "hello world";
    *s = 'H';
}
> cc -g -o segfault segfault.c
> limit coredumpsize 9999999
> ./segfault `perl -le 'print "blah$_" for 1..999'`
Segmentation fault (core dumped)
> strings core.12231 | grep -c blah
1000

Then with some quick altagoobingleduckgoing of gdb, and assuming debug symbols, this can be recovered via something like:

> gdb ./segfault core.12231
...
(gdb) p argc
$1 = 1000
(gdb) x/1000s *argv
...

Another option would be to use a simple shell wrapper that logs "$@" somewhere then execs the proper program with the given arguments.

  • I don't know why that didn't occur to me earlier, but thanks for the quick response and example :) – user812786 Feb 8 '16 at 20:13
  • strings -n100 coredumpfile :P – Hitechcomputergeek Jun 1 '17 at 12:46
1

I've written a pargs version for Linux. Thus, given the core file, you can display all arguments with it under RHEL 6, as well:

$ pargs core.MyApplication.1234
argv[0]: /usr/libexec/gvfsd-network
argv[1]: --spawner
argv[2]: :1.16
argv[3]: /org/gtk/gvfs/exec_spaw/2

Alternatively, if you have gdb and the executable still available you can display all arguments with GDB:

$ gdb MyApplication core.MyApplication.1234
(gdb) bt
[..]
#4  0x000055a376101e1b in main (argc=4, argv=0x7ffca4780f08)
                       at daemon-main-generic.c:45
(gdb) frame 4
(gdb) set print address off
(gdb) show print pretty
(gdb) p *argv@argc
$1 = {"/usr/libexec/gvfsd-network", "--spawner", ":1.16",
      "/org/gtk/gvfs/exec_spaw/2"}

Comparing the two approaches, pargs just requires a core file and doesn't need further interactive input.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.