Find Which Program Caused a Core Dump File

Find which program caused a core dump file

You can simply use the file program to identify them:

E.g

# file /var/core/core
/var/core/core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'

How can I figure out the program that caused core dump?

Run the Console utility, found in /Applications/Utilities. Look under DIAGNOSTIC AND USAGE INFORMATION for User Diagnostic Reports and System Diagnostic Reports. There should be an entry for each recent crash, with the name of the program, date, time, and host name. You can click on each of these for additional information.

You can also just access the diagnostic reports directly in the file system. User Diagnostic Reports are in ~/Library/Logs/DiagnosticReports/ and System Diagnostic Reports are in /Library/Logs/DiagnosticReports/.

linux: is there a way to find out which process generated a core file?

So it there any process id related information inside core files

Definitely.

In the core file, there is a set of ELF notes. The note you are looking for is of type NT_PRPSINFO, and it contains (among other things) pr_pid that you want:

typedef struct prpsinfo {       /* Information about process                 */
unsigned char pr_state; /* Numeric process state */
char pr_sname; /* Char for pr_state */
unsigned char pr_zomb; /* Zombie */
signed char pr_nice; /* Nice val */
unsigned long pr_flag; /* Flags */
uint32_t pr_uid; /* User ID */
uint32_t pr_gid; /* Group ID */

pid_t pr_pid; /* Process ID */
pid_t pr_ppid; /* Parent's process ID */
pid_t pr_pgrp; /* Group ID */
pid_t pr_sid; /* Session ID */
char pr_fname[16]; /* Filename of executable */
char pr_psargs[80]; /* Initial part of arg list */

} prpsinfo;

The question is: which tool(s) can find and decode this note. Try eu-readelf from elfutils.

How do I analyze a program's core dump file with GDB when it has command-line parameters?

You can use the core with GDB in many ways, but passing parameters which is to be passed to the executable to GDB is not the way to use the core file. This could also be the reason you got that error. You can use the core file in the following ways:

gdb <executable> <core-file> or gdb <executable> -c <core-file> or

gdb <executable>
...
(gdb) core <core-file>

When using the core file you don't have to pass arguments. The crash scenario is shown in GDB (checked with GDB version 7.1 on Ubuntu).

For example:

$ ./crash -p param1 -o param2
Segmentation fault (core dumped)
$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2'. <<<<< See this line shows crash scenario
Program terminated with signal 11, Segmentation fault.
#0 __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

If you want to pass parameters to the executable to be debugged in GDB, use --args.

For example:

$ gdb --args ./crash -p param1 -o param2
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) r
Starting program: /home/@@@@/crash -p param1 -o param2

Program received signal SIGSEGV, Segmentation fault.
__strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)

Man pages will be helpful to see other GDB options.

Most useful commands are:

  • bt (backtrace)
  • info locals (show values of local variables)
  • info registers (show values of CPU registers)
  • frame X (change to stack frame X)
  • up and down (navigate in the stack frame (call chain))

Where can I find a Raku core dump file?

/var/crash is for system crash dumps. Core dumps are usually saved under /var/lib/systemd/coredump/, if not, then it might help to also tell us your distribution and whether your system uses systemd. Also check /etc/systemd/coredump.conf for custom settings.



Related Topics



Leave a reply



Submit