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
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 = 1 kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t fs.suid_dumpable = 2
Save and close the file. Where,
- kernel.core_uses_pid = 1 – Appends the coring processes PID to the core file name.
- fs.suid_dumpable = 2 – Make sure you get core dumps for setuid programs.
- 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:
Please note that DAEMON_COREFILE_LIMIT is Redhat specific, for all other distro add configuration as follows:
ulimit -c unlimited >/dev/null 2>&1 echo /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
Now, you can send core files to vendor or software writes.
How Do I Read Core Files?
You need use the gdb command as follows:
$ gdb /path/to/application /path/to/corefile
See the gdb command man page for more information.
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.
- Debugging Tip: Trace the Process and See What It is Doing with strace
- The Art of Debugging with GDB, DDD, and Eclipse
- man pages core(5), strace, and bash
Stay tunned for gdb tutorial which will explains how to use generated core file to track down problem.