用apport调试专有程序(ubuntu)

时间:2014-06-03 08:39:39

标签: debugging ubuntu crash coredump

我编译和执行的程序(通过shell脚本,作为另一个用户)有时崩溃:

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

我想查看核心文件,找出可能发生崩溃的位置。不幸的是,没有找到标准的核心文件,但显然Ubuntu称它是默认的崩溃处理程序apport,它在日志中说:

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

我一直在尝试使用apport-retrace处理崩溃转储文件,但apport不能很好地处理该文件,因为它显然需要特定于Ubuntu的软件包:     错误:报告文件不包含以下必填字段之一:CoreDump DistroRelease Package ExecutablePath

查看崩溃转储文件,我认为里面有重要的调试信息,所以我的问题是:是否有另一种处理此文件的方法,使用gdb,或者如果核心转储确实存储,则从中提取核心转储文件内?

供参考,这里是(部分).crash文件:

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)

0 个答案:

没有答案