1

A program I compiled and executed (by a shell script, as another user) sometimes crashes:

./run.sh: line 19:  7964 Segmentation fault      (core dumped) ./Program ARG1 ARG2 ARG3 2>&1

I wanted to take a look at the core file to figure out where the crash might have happened. Unfortunately, there's no standard core file to be found, but apparently Ubuntu called it's default crash handler apport, which says in its log:

ERROR: apport (pid 8841) Mon Jun  2 17:59:04 2014: called for pid 7964, signal 11, core limit 0
ERROR: apport (pid 8841) Mon Jun  2 17:59:04 2014: executable: /path/to/Program (command line "./Program ARG1 ARG2 ARG3")
ERROR: apport (pid 8841) Mon Jun  2 17:59:04 2014: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 8841) Mon Jun  2 17:59:16 2014: wrote report /var/crash/_path_to_Program.1001.crash

I've been trying to process the crash dump file with apport-retrace, but apport doesn't handle the file very well because it apparently expects Ubuntu-specific packages: ERROR: report file does not contain one of the required fields: CoreDump DistroRelease Package ExecutablePath

Looking at the crash dump file, I think there's important debugging information inside, so my question: is there another way to process this file, either with gdb, or extract a core dump file from it if the core dump is indeed stored inside?

For reference, here's (partially) the .crash file:

ProblemType: Crash
Architecture: amd64
Date: Mon Jun  2 17:59:04 2014
DistroRelease: Ubuntu 13.04
ExecutablePath: /path/to/Program
ExecutableTimestamp: 1401723071
ProcCmdline: ./Program ARG1 ARG2 ARG3
ProcCwd: /path/to
ProcEnviron: PATH=(custom, no user)
ProcMaps:
    ... (memory map left out)

ProcStatus:
 Name:  Program
 State: S (sleeping)
 Tgid:  7964
 Pid:   7964
 PPid:  7963
 TracerPid:     0
 Uid:   1001    1001    1001    1001
 Gid:   1001    1001    1001    1001
 FDSize:        64
 Groups:        4 27 1001 
 VmPeak:         1009888 kB
 VmSize:         1009884 kB
 VmLck:        0 kB
 VmPin:        0 kB
 VmHWM:   205400 kB
 VmRSS:   205400 kB
 VmData:          762620 kB
 VmStk:      136 kB
 VmExe:     3312 kB
 VmLib:    64144 kB
 VmPTE:      852 kB
 VmSwap:               0 kB
 Threads:       9
 SigQ:  0/127009
 SigPnd:        0000000000000000
 ShdPnd:        0000000000000000
 SigBlk:        0000000000000000
 SigIgn:        0000000000001206
 SigCgt:        0000000180000000
 CapInh:        0000000000000000
 CapPrm:        0000000000000000
 CapEff:        0000000000000000
 CapBnd:        0000001fffffffff
 Seccomp:       0
 Cpus_allowed:  ff
 Cpus_allowed_list:     0-7
 Mems_allowed:  00000000,00000001
 Mems_allowed_list:     0
 voluntary_ctxt_switches:       3669360
 nonvoluntary_ctxt_switches:    85456
Signal: 11
Uname: Linux 3.8.0-35-generic x86_64
UserGroups: adm sudo
CoreDump: base64
 H4sICAAAAAAC/0NvcmVEdW1wAA==
 ... (huge base64 encoded string left out)
xsmet
  • 11
  • 3
  • you could ask to migrate this question to unix.stackexchange.com; or fully copy this question there, then delete this one. – Aquarius Power Aug 02 '14 at 02:01
  • This similar question will help you resolve you problem https://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-the-current-directory/18368068#18368068 – LLLDaniel Apr 25 '22 at 01:36

0 Answers0