Collecting Problem Data

Core files contain useful information, if they are complete. Sometimes you need to configure your system to make sure you can save complete core files. Consider the following items to ensure you can create complete core files.

The following subsections provide additional details on each of these steps.

Ensure Process Can Write Large Core Files

Check your coredump block size to make sure it is set to unlimited using the ulimit -a command:

$ ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) 4292870144 stack(kbytes) 8192 memory(kbytes) unlimited coredump(blocks) 4194303

If coredump is not set to unlimited, set it to unlimited using the ulimit -c command:

$ ulimit -c unlimited $ ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) 4292870144 stack(kbytes) 8192 memory(kbytes) unlimited coredump(blocks) unlimited

Verify Amount of Disk Space

Check the amount of disk space available in the current working directory using the df -kP command:

$ df -kP /home/mycurrentdir Filesystem 1024-blocks Used Available Capacity Mounted on /dev/vg00/lvol5 1022152 563712 458440 56% /home

Check If Directory Supports Large File Systems

Use the fsadm command as root to check if your directory supports large file systems. If you do not execute this command as root, you may not retrieve meaningful results. Following is an example:

<root>$ /usr/sbin/fsadm <mount_point>

The following example output shows a /extra file system that is set up to support large files and a /stand file system that is not set up to support large files:

<root>$ /usr/sbin/fsadm /extra fsadm: /etc/default/fs is used for determining the file system type largefiles <root>$ /usr/sbin/fsadm /stand fsadm: /etc/default/fs is used for determining the file system type nolargefiles

You can use the /usr/sbin/fsadm command to set the directory to support large files. For example, to convert an hfs file system from nolargefiles to largefiles, issue the following command:

$ fsadm -f hfs -o largefiles /dev/vg02/lvol1

Alternatively, if the directory does not support large file systems, you can write the core file to a different directory. Do this by setting the JAVA_CORE_DESTINATION environment variable (available starting with SDK 1.4.2) to the name of the directory and create the directory. For example:

$ export JAVA_CORE_DESTINATION=<alt_dir> $ mkdir $JAVA_CORE_DESTINATION

Java creates a directory named core under the JAVA_CORE_DESTINATION directory where the core and hs_err_pid<pid>.log files are written. For example:

$ cd $JAVA_CORE_DESTINATION $ ls core.29757 $ ll core.29757 total 429296 -rw------- 1 test users 219781020 Aug 29 12:33 core -rw-rw-rw- 1 test users 2191 Aug 29 12:33 hs_err_pid29757.log

Ensure Permissions Allow Core Files

Some Java processes run setuid; that is, a process where the effective uid or gid differs from the real uid or gid. On HP-UX 11i v1 (11.11) and later versions a kernel security feature prevents core file creation for these processes. Use the following command when you are logged in as the root user to enable core dumps of setuid Java processes:

$ echo "dump_all/W 1" | adb -w /stand/vmunix /dev/kmem

This capability is turned on only for the current boot.

Analyzing the core file is essential for troubleshooting problems. Core files are automatically generated for application aborts. For hung processes and performance issues, you need to generate them using the gdb dumpcore command.

The gdb dumpcore command forces the generation of a core file without killing a running process. This command causes a core file named core.<pid> to be created. The current process state is not modified when this command is issued.

The following example shows a Java application running on an Integrity system:

$ echo "dumpcore\nq" > gdb_cmds 
$ ps -u myuser | grep java 
12290 pts/6  12:58 java 
$ gdb --command=gdb_cmds -batch /opt/java1.4/bin/IA64N/java 12290 

This generates a core file in the current directory with the name core.12290.

On HP-UX 11i v3 (11.31), another way to generate a core file is by using the gcore command. The following example shows invocation of gcore to dump the core image of process 11050. The core image is written to the core.11050 file by default:

$ gcore 11050

After you have successfully collected your core file, you should verify that it is complete and valid with the following two steps.

First, open the core file in gdb and check the error and warning messages. If the message “<corefilename> is not a core dump: File format not recognized“ is displayed when you open the file, your core file is invalid. The following example shows how to verify a core file produced by a 32-bit application on a PA-RISC system. In this example, the core file is valid.

$ gdb /opt/java1.4/jre/lib/PA_RISC2.0/server/libjunwind.sl core 
HP gdb 5.5.7 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00 and target hppa1.1-hp-hpux11.00. 
Copyright 1986 - 2001 Free Software Foundation, Inc. 
Hewlett-Packard Wildebeest 5.5.7 (based on GDB) is covered by the GNU General Public License. 
Type "show copying" to see the conditions to change it and/or distribute copies. 
Type "show warranty" for warranty/support.
.. 
Core was generated by `java'. Program terminated with signal 6, Aborted.  

#0  0xc0214db0 in kill+0x10 () from ./libc.2

Second, check to make sure that the core file was not truncated by issuing the “what core” command. If you do not see the dld.sl version at the bottom of the what output, then the core file is truncated and is not usable. In the following example, the dld.sl version exists at the bottom of the what output, so you know the core file is not truncated:

$ what core
 core: 
some other library names and version information ... 
92453-07 dld dld dld.sl B.11.48 EXP 051121