Determining Location and Cause of "core" File

About This Document

1. Log in as root.

2. Run errpt -a | pg and look for the word CORE_DUMP. Note the file system Serial Number and the Inode Number from the CORE_DUMP error log entry. Here is an example:

    
       ERROR LABEL:  CORE_DUMP 
       . . . 
       File system Serial Number 
                  8 
       Inode Number 
               2049 
   

3. Run echo vfs | crash > file. Then look at the output (in "file") to find the file system with the Serial Number found in step 2. It will be in the column labeled NUMBER.

   Example lines from "file":

    
   >VFS ADDRESS   TYPE OBJECT   STUB NUMBER FLAGS   PATHS 
     5 583b4f4     jfs 5843108   58436b8     8 D     /dev/hd1 mounted 
     over /home 
   

   Note the directory following mounted over in the PATHS section (/home in the example above).

4. Now run the following command, replacing <dir> with the directory found in step 3 and replacing <inum> with the Inode Number found in step 2:

    
       find <dir> -xdev -inum <inum> -print 
   

   Here is example output from the find command:

    
       /home/user_name 
   

   The output above is the directory in which the "core" file resides.

   An alternate method to locate core files is to use the find command with:

    
       find / -name core -ls 
   

   Then look for a core file with the same date and time as the entry in the errpt.

5. Now cd to the directory indicated in step 4.

6. Run the following command:

 
    /usr/sbin/hdf core 730 64 

The program that caused the core dump is listed on the 730 line.

For example:

 
00000730  6D65646C 65790000 00000000 00000000  |tsm...........| 

The program that caused the core dump will be listed at the right-hand side of the line, between vertical bars (pipe symbols). In the preceding example, the core file shows the tsm program core dumped.

If you recognize the program's name as one of your applications, you need to give the "core" file to your application supplier for further problem determination.

If the program listed is an AIX command, or if you are unsure of its origin, you may wish to work with AIX support on this problem.

You should run dbx on the binary executable that caused the core dump. The dbx utility is included in the bos.adt.debug fileset. The dbx utility can display the offending system call.

In the following example the program that caused the core dump is sleep. After running dbx against the sleep command, the offending system call was sleep. AIX Support Personnel may ask for this information in some cases.

 
    dbx /usr/bin/sleep core 
    Type 'help' for help: 
    reading symbolic information ...warning: no source compiled with -g 
    [using memory image in core] 
    Segmentation fault in sleep at 0xd0019cd8 
    0xd0019cd8 (sleep+0x40)  80410014       1    r2,0x14(rl) 
    (dbx) where 
    sleep(??) at 0xd0019cd8 
    main(??, ??) at 0x10000378 
    (dbx) quit 

If AIX support personnel determine that the core dump needs to be sent in to the support center, then the output of the snap -g command should be sent in also. This gathers the output of the lslpp -hBc command, which is required to recreate exact operating system environments.

A core file is generated when a program tries to do something illegal on the system. The usual cause is trying to access memory outside the memory assigned to the program by the system. Core files are normally caused by a program error or some type of data corruption.

Unless the program that caused the core file is a special debug version of the program, normally the only useful information in the core file is the name of the module or program that caused a core dump.

Examining the errpt -a log will frequently alert you to possible problems with the system that may be the cause of the core file.