Where did that Core File Come From?
Whenever UNIX encounters a fatal error, it dumps an
image of the halted
process into a file named core. Many different types
can cause a core dump. The most common are memory violations,
instructions, bus errors, and user-generated quit signals.
can be nasty disk consumers, especially since many core
essentially worthless -- the product of quit signals
users (who think the system is hung if their 100-megabyte
However, some core files are extremely important. To
a working developer,
the core file holds a vast wealth of debugging information:
the core file, he can find out exactly what his program
when it was halted.
For the most part, however, when we system administrators
annoying core files, we have no idea what caused them
and thus, no
reliable basis for deciding whether to delete them.
In 1988, a program called psc appeared on USENET. This
looks inside the core file and extracts information
about the core
dump, including important clues to the origin of the
core file. This
article explains psc and the related file structures.
As part of each process, UNIX maintains a per process
which contains the user environment. This user environment
the process, and is part of the information which is
saved as part
of a core dump. The per-process user area also includes
as they were at the time of the fault. The actual size
of the user
area is implementation-dependent, but is defined in
the system include
file /usr/include/sys/param.h. The remainder of the
represents the actual contents of the user's memory
when the image
was written to disk.
The system header file /usr/include/sys/user.h describes
per-process user area, and /usr/include/sys/reg.h gives
location of the register values.
The program is fairly straight forward, amounting to
only 81 lines
By default, psc opens a file named "core"
if it exists
in the current directory. Alternatively, the user may
use a command
line path argument to specify which file is to be examined.
opens the file, and loads the per user process structure
data from the file's user area.
Figure 1 shows a typical psc report. The effective and
user ID numbers tell which user was running the process
when the process
died. Note that if the effective user ID is different
from the real
user ID, a core image will not be generated when the
The "process times" section reports the parent
and child process
times which had accumulated prior to the dump. The user
the amount of time which was spent operating in user
mode (as opposed
to kernel or system mode).
The "process misc" section gives the tty major
minor numbers and the address of the process structure
for the process
which created this core dump. On its own, the process
may not be useful, but armed with this information and
you can peruse the entire process slot entry. The controlling
major and minor numbers tell who was executing the program,
The IPC section reports on the active interprocess communication
A value of "proc" in this section indicates
that the process
was locked into RAM, "text" indicates that
the text portion
was locked, and "data" indicates that the
data portion was
locked. Unless the offending program specifically asked
to lock its text or data area, this section will report
The FILE I/O section defines the output parameters which
when the program crashed. The base I/O address points
to the I/O control
structure. "Offset" is the file offset at
the time. "Bytes
remaining" reports how much data was left when
the process aborted.
This section also reports what umask was being applied
to files which
were created by this program. The ulimit value indicates
file size (in blocks) which could be created by this
The "accounting" section reports which process
core file, how much memory was used by the process,
whether the process
was created via fork or exec system call, and when the
Though psc is a simple program, it is an important system
tool. The information psc reports can prove invaluable
the cause of a core dump and in determining whether
a particular core
file needs to be preserved.
About the Author
Chris Hare is Ottawa Technical Services Manager for
Systems, Inc. He has worked in the UNIX environment
since 1986 and
in 1988 became one the first SCO authorized instructors
He teaches UNIX introductory, system administration,
classes. His current focus is on networking, Perl, and