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?
Recover full command that generated core dump
rhel;core dump
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 blah1000Then 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.