Core files and crash dumps are generated when a process or application terminates abnormally. You can also generate core files and crash dumps to help diagnose why a process does not respond to client application requests.
This section includes the following procedures:
This procedure shows you how to use the coreadm command to configure the system so that all process core files are placed in a single system directory. This means it is easier to track problems by examining core files in a specific directory whenever a Solaris OS process or daemon terminates abnormally.
Make sure that the /var file system where the core files are generated has sufficient space. Once you configure Solaris OS to generate core files as shown here, all processes that crash write a core file to the /var/cores directory.
Run the following commands as root.
mkdir -p /var/cores coreadm -g /var/cores/%f.%n.%p.%t.core -e global -e global-setid -e log -d process -d proc-setid
In this command:
Specifies the global core file name pattern. Unless a per-process pattern or setting overrides it, core files are stored in the specified directory with a name such as program.node.pid.time.core, for example: mytest.myhost.1234.1102010309.core.
Specifies options to enable. The preceding command enables:
Use of the global (that is, system-wide) core file name pattern (and thereby location)
Capability of setuid programs to also dump core as per the same pattern
Generation of a syslog message by any attempt to dump core (successful or not)
Specifies options to disable. The preceding command disables:
Core dumps per the per-process core file pattern
Per-process core dumps of setuid programs
The preceding command stores all core dumps in a central location with names identifying what process dumped core and when. These changes only impact processes started after you run the coreadm command. Use the coreadm -u command after the preceding command to apply the settings to all existing processes.
Display the core configuration.
# coreadmglobal core file pattern: /var/cores/%f.%n.%p.%t.core init core file pattern: core global core dumps: enabled per-process core dumps: disabled global setid core dumps: enabled per-process setid core dumps: disabled global core dump logging: enabled
See the coreadm man page for further information.
Set the file size as large as possible, using the ulimit command.
# ulimit -c unlimited # ulimit -a coredump(blocks) unlimited
See the ulimit(1) man page for details.
Verify that applications can in fact generate core files.
# cd /var/cores # sleep 100000 &  pid # kill -8 pid # ls
You should see a core file for the sleep process you killed.
On Red Hat systems, you can enable core files to be generated on a per user basis.
Open the ~/.bash_profile file for the server user in a text editor.
Search for a line using the ulimit command as follows.
ulimit -S -c 0 > /dev/null 2>&1
Either comment out the line, or set your own limit for core file size.
The native debug tool on Windows systems, Dr. Watson, allows you to generate crash dumps.
However, Dr. Watson does not allow generation of crash dumps on a running process. To generate crash dumps from a running process, install the Debugging Tools. The Debugging Tools are freely available from the Windows web site at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
You can use Dr. Watson for crash dumps generated when a process dies.
Use the Window Debugging Tools to generate crash dumps of a running process.
Enable generation of a crash dump for your application.
Get the process ID of the application using the tlist.exe command, then enable the crash dump.
win-dbg-root\adplus.vbs -crash -FullOnFirst -p pid -o C:\dump-dir
The adplus.vbs command tracks the application with process ID pid. The adplus.vbs command generates a dmp file in the event of a crash.
When collecting crash dump information, take the complete folder generated under C:\dump-dir.
The pkg_app script packages an executable and all of its shared libraries into one compressed tar file given the process ID of the application, and optionally the name of the core file to be opened. The files are stripped of their directory paths, and are stored under a relative directory named app/ with their names only, allowing them to be unpacked in one directory.
On Solaris 9 and Solaris 10, the list of files is derived from the core file rather than the process image if it is specified. You must still provide the process ID of the running application to assist in path resolution.
Two scripts are created to facilitate opening the core file when the tar file is unpacked.
opencore. This is the script to be executed once unpacked. It sets the name of the core file and the linker path to use the app/ directory, and then invokes dbx with the dbxrc file as the argument.
dbxrc. This script contains the dbx initialization commands to open the core file.