HowTo: Debug Crashed Linux Application Core Files Like A Pro

Core dumps are often used to diagnose or debug errors in Linux or UNIX programs. Core dumps can serve as useful debugging aids for sys admins to find out why Application like Lighttpd, Apache, PHP-CGI or any other program crashed. Many vendors and open source project author requests a core file to troubleshoot a program. A core file is generated when an application program abnormally terminates due to bug, operating system security protection schema, or program simply try to write beyond the area of memory it has allocated, and so on. This article explains how to turn on core file support and track down bugs in programs.

Turn On Core File Creation Support

By default most Linux distributions turn off core file creation (at least this is true for RHEL, CentOS, Fedora and Suse Linux). You need to use the ulimit command to configure core files.

See The Current Core File Limits

Type the following command:

# ulimit -c

Sample outputs:

0

The output 0 (zero) means core file is not created.

Change Core File Limits

In this example, set the size limit of core files to 75000 bytes:

# ulimit -c 75000

HowTo: Enable Core File Dumps For Application Crashes And Segmentation Faults

Edit /etc/profile file and find line that read as follows to make persistent configuration:

ulimit -S -c 0 > /dev/null 2>&1

Update it as follows:

ulimit -c unlimited >/dev/null 2>&1

Save and close the file. Edit /etc/sysctl.conf, enter:

# vi /etc/sysctl.conf

Append the following lines:

kernel.core_uses_pid = 1kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%tfs.suid_dumpable = 2

Save and close the file. Where,

1. kernel.core_uses_pid = 1 – Appends the coring processes PID to the core file name.
2. fs.suid_dumpable = 2 – Make sure you get core dumps for setuid programs.
3. kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t – When the application terminates abnormally, a core file should appear in the /tmp. The kernel.core_pattern sysctl controls exact location of core file. You can define the core file name with the following template whih can contain % specifiers which are substituted by the following values when a core file is created:

• %% – A single % character
• %p – PID of dumped process
• %u – real UID of dumped process
• %g – real GID of dumped process
• %s – number of signal causing dump
• %t – time of dump (seconds since 0:00h, 1 Jan 1970)
• %h – hostname (same as ’nodename’ returned by uname(2))
• %e – executable filename

Finally, enable debugging for all apps, enter (Redhat and friends specific):

# echo "DAEMON_COREFILE_LIMIT='unlimited'" >> /etc/sysconfig/init

Reload the settings in /etc/sysctl.conf by running the following command:

# sysctl -p

How Do I Enable Core Dumping For Specific Deamon?

To enable core dumping for specific deamons, add the following line in the /etc/sysconfig/daemon-file file. In this example, edit /etc/init.d/lighttped and add line as follows:

DAEMON_COREFILE_LIMIT='unlimited'

Please note that DAEMON_COREFILE_LIMIT is Redhat specific, for all other distro add configuration as follows:

ulimit -c unlimited >/dev/null 2>&1echo /tmp/core-%e-%s-%u-%g-%p-%t > /proc/sys/kernel/core_pattern

Save and close the file. Restart / reload lighttpd:

# /etc/init.d/lighttpd restart# su - lighttpd$ ulimit -c

Sample outputs:

unlimited

Now, you can send core files to vendor or software writes.

How Do I Read Core Files?

gdb command

You need use the gdb command as follows:

$ gdb /path/to/application /path/to/corefile

Refer to gdb man page for more information:

$ man gdb

strace command

System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. This is also useful to submit bug reports to open source developers. See how to use the strace command under Linux to debug the problems.

strace is a useful diagnostic, instructional, and debugging tool. It can save lots of headache. System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. This is also useful to submit bug reports to open source developers.

Each line in the trace contains the system call name, followed by its arguments in parentheses and its return value.

Run strace against /bin/foo and capture its output to a text file in output.txt:

$ strace -o output.txt /bin/foo

You can strace the webserver process and see what it’s doing. For example, strace php5 fastcgi process, enter:

$ strace -p 22254 -s 80 -o /tmp/debug.lighttpd.txt

To see only a trace of the open, read system calls, enter :

$ strace -e trace=open,read -p 22254 -s 80 -o debug.webserver.txt

Where,

• -o filename : Write the trace output to the file filename rather than to screen (stderr).
• -p PID : Attach to the process with the process ID pid and begin tracing. The trace may be terminated at any time by a keyboard interrupt signal (hit CTRL-C). strace will respond by detaching itself from the traced process(es) leaving it (them) to continue running. Multiple -p options can be used to attach to up to 32 processes in addition to command (which is optional if at least one -p option is given).
• -s SIZE : Specify the maximum string size to print (the default is 32).

Refer to strace man page for more information:

$ man strace

From:

【1】HowTo: Debug Crashed Linux Application Core Files Like A Pro
【2】Debugging Tip: Trace the Process and See What It is Doing with strace