File Formats core(4)
NAME
core - process core file
DESCRIPTION
The operating system writes out a core file for a process
when the process is terminated due to receiving certain sig-
nals. A core file is a disk copy of the contents of the pro-
cess address space at the time the process received the sig-
nal, along with additional information about the state of
the process. This information can be consumed by a debugger.
Core files can also be generated by applying the gcore(1)
utility to a running process.
Typically, core files are produced following abnormal termi-
nation of a process resulting from a bug in the correspond-
ing application. Whatever the cause, the core file itself
provides invaluable information to the programmer or support
engineer to aid in diagnosing the problem. The core file can
be inspected using a debugger such as dbx(1) or mdb(1) or by
applying one of the proc(1) tools.
The operating system attempts to create up to two core files
for each abnormally terminating process, using a global core
file name pattern and a per-process core file name pattern.
These patterns are expanded to determine the pathname of the
resulting core files, and can be configured by coreadm(1M).
By default, the global core file pattern is disabled and not
used, and the per-process core file pattern is set to core.
Therefore, by default, the operating system attempts to
create a core file named core in the process's current work-
ing directory.
A process terminates and produces a core file whenever it
receives one of the signals whose default disposition is to
cause a core dump. The list of signals that result in gen-
erating a core file is shown in signal.h(3HEAD). Therefore,
a process might not produce a core file if it has blocked or
modified the behavior of the corresponding signal. Addition-
ally, no core dump can be created under the following condi-
tions:
o If normal file and directory access permissions
prevent the creation or modification of the per-
process core file pathname by the current process
user and group ID. This test does not apply to the
global core file pathname because, regardless of
the UID of the process dumping core, the attempt to
write the global core file is made as the
superuser.
SunOS 5.11 Last change: 13 May 2008 1
File Formats core(4)
o Core files owned by the user nobody will not be
produced. For example, core files generated for the
superuser on an NFS directory are owned by nobody
and are, therefore, not written.
o If the core file pattern expands to a pathname that
contains intermediate directory components that do
not exist. For example, if the global pattern is
set to /var/core/%n/core.%p, and no directory
/var/core/`uname -n` has been created, no global
core files are produced.
o If the destination directory is part of a filesys-
tem that is mounted read-only.
o If the resource limit RLIMITCORE has been set to 0
for the process, no per-process core file is pro-
duced. Refer to setrlimit(2) and ulimit(1) for more
information on resource limits.
o If the core file name already exists in the desti-
nation directory and is not a regular file (that
is, is a symlink, block or character special-file,
and so forth).
o If the kernel cannot open the destination file
OEXCL, which can occur if same file is being
created by another process simultaneously.
o If the process's effective user ID is different
from its real user ID or if its effective group ID
is different from its real group ID. Similarly,
set-user-ID and set-group-ID programs do not pro-
duce core files as this could potentially comprom-
ise system security. These processes can be expli-
citly granted permission to produce core files
using coreadm(1M), at the risk of exposing secure
information.
The core file contains all the process information pertinent
to debugging: contents of hardware registers, process
status, and process data. The format of a core file is
object file specific.
For ELF executable programs (see a.out(4)), the core file
generated is also an ELF file, containing ELF program and
file headers. The etype field in the file header has type
ETCORE. The program header contains an entry for every seg-
ment that was part of the process address space, including
shared library segments. The contents of the mappings
SunOS 5.11 Last change: 13 May 2008 2
File Formats core(4)
specified by coreadm(1M) are also part of the core image.
Each program header has its pmemsz field set to the size of
the mapping. The program headers that represent mappings
whose data is included in the core file have their pfilesz
field set the same as pmemsz, otherwise pfilesz is zero.
A mapping's data can be excluded due to the core file con-
tent settings (see coreadm(1M)), or due to some failure. If
the data is excluded because of a failure, the program
header entry will have the PFSUNWFAILURE flag set in its
pflags field.
The program headers of an ELF core file also contain entries
for two NOTE segments, each containing several note entries
as described below. The note entry header and core file note
type (ntype) definitions are contained in . The
first NOTE segment exists for binary compatibility with old
programs that deal with core files. It contains structures
defined in . New programs should recognize
and skip this NOTE segment, advancing instead to the new
NOTE segment. The old NOTE segment is deleted from core
files in a future release.
The old NOTE segment contains the following entries. Each
has entry name "CORE" and presents the contents of a system
structure:
prpsinfot ntype: NTPRPSINFO. This entry contains
information of interest to the ps(1) com-
mand, such as process status, CPU usage,
nice value, controlling terminal, user-ID,
process-ID, the name of the executable, and
so forth. The prpsinfot structure is
defined in .
char array ntype: NTPLATFORM. This entry contains a
string describing the specific model of the
hardware platform on which this core file
was created. This information is the same as
provided by sysinfo(2) when invoked with the
command SIPLATFORM.
auxvt array ntype: NTAUXV. This entry contains the
array of auxvt structures that was passed
by the operating system as startup informa-
tion to the dynamic linker. Auxiliary vector
information is defined in .
SunOS 5.11 Last change: 13 May 2008 3
File Formats core(4)
Following these entries, for each active (non-zombie)
light-weight process (LWP) in the process, the old NOTE seg-
ment contains an entry with a prstatust structure, plus
other optionally-present entries describing the LWP, as fol-
lows:
prstatust ntype: NTPRSTATUS. This structure contains
things of interest to a debugger from the
operating system, such as the general regis-
ters, signal dispositions, state, reason for
stopping, process-ID, and so forth. The
prstatust structure is defined in
.
prfpregsett ntype: NTPRFPREG. This entry is present
only if the LWP used the floating-point
hardware. It contains the floating-point
registers. The prfpregsett structure is
defined in .
gwindowst ntype: NTGWINDOWS. This entry is present
only on a SPARC machine and only if the sys-
tem was unable to flush all of the register
windows to the stack. It contains all of the
unspilled register windows. The gwindowst
structure is defined in .
prxregsett ntype: NTPRXREG. This entry is present
only if the machine has extra register state
associated with it. It contains the extra
register state. The prxregsett structure is
defined in .
The new NOTE segment contains the following entries. Each
has entry name "CORE" and presents the contents of a system
structure:
psinfot ntype: NTPSINFO. This structure con-
tains information of interest to the
ps(1) command, such as process status,
CPU usage, nice value, controlling ter-
minal, user-ID, process-ID, the name of
the executable, and so forth. The
psinfot structure is defined in
.
SunOS 5.11 Last change: 13 May 2008 4
File Formats core(4)
pstatust ntype: NTPSTATUS. This structure con-
tains things of interest to a debugger
from the operating system, such as pend-
ing signals, state, process-ID, and so
forth. The pstatust structure is
defined in .
char array ntype: NTPLATFORM. This entry contains
a string describing the specific model
of the hardware platform on which this
core file was created. This information
is the same as provided by sysinfo(2)
when invoked with the command
SIPLATFORM.
auxvt array ntype: NTAUXV. This entry contains the
array of auxvt structures that was
passed by the operating system as
startup information to the dynamic
linker. Auxiliary vector information is
defined in .
struct utsname ntype: NTUTSNAME. This structure con-
tains the system information that would
have been returned to the process if it
had performed a uname(2) system call
prior to dumping core. The utsname
structure is defined in .
prcredt ntype: NTPRCRED. This structure con-
tains the process credentials, including
the real, saved, and effective user and
group IDs. The prcredt structure is
defined in . Following
the structure is an optional array of
supplementary group IDs. The total
number of supplementary group IDs is
given by the prngroups member of the
prcredt structure, and the structure
includes space for one supplementary
group. If prngroups is greater than 1,
there is prngroups - 1 gidt items fol-
lowing the structure; otherwise, there
is no additional data.
char array ntype: NTZONENAME. This entry contains
a string which describes the name of the
SunOS 5.11 Last change: 13 May 2008 5
File Formats core(4)
zone in which the process was running.
See zones(5). The information is the
same as provided by getzonenamebyid(3C)
when invoked with the numerical ID
returned by getzoneid(3C).
struct ssd array ntype: NTLDT. This entry is present
only on an 32-bit x86 machine and only
if the process has set up a Local
Descriptor Table (LDT). It contains an
array of structures of type struct ssd,
each of which was typically used to set
up the %gs segment register to be used
to fetch the address of the current
thread information structure in a mul-
tithreaded process. The ssd structure is
defined in .
corecontentt ntype: NTCONTENT. This optional entry
indicates which parts of the process
image are specified to be included in
the core file. See coreadm(1M).
Following these entries, for each active and zombie LWP in
the process, the new NOTE segment contains an entry with an
lwpsinfot structure plus, for a non-zombie LWP, an entry
with an lwpstatust structure, plus other optionally-present
entries describing the LWP, as follows. A zombie LWP is a
non-detached LWP that has terminated but has not yet been
reaped by another LWP in the same process.
lwpsinfot ntype: NTLWPSINFO. This structure contains
information of interest to the ps(1) command,
such as LWP status, CPU usage, nice value,
LWP-ID, and so forth. The lwpsinfot struc-
ture is defined in . This is
the only entry present for a zombie LWP.
lwpstatust ntype: NTLWPSTATUS. This structure contains
things of interest to a debugger from the
operating system, such as the general regis-
ters, the floating point registers, state,
reason for stopping, LWP-ID, and so forth.
The lwpstatust structure is defined in
>.
SunOS 5.11 Last change: 13 May 2008 6
File Formats core(4)
gwindowst ntype: NTGWINDOWS. This entry is present
only on a SPARC machine and only if the sys-
tem was unable to flush all of the register
windows to the stack. It contains all of the
unspilled register windows. The gwindowst
structure is defined in .
prxregsett ntype: NTPRXREG. This entry is present only
if the machine has extra register state asso-
ciated with it. It contains the extra regis-
ter state. The prxregsett structure is
defined in .
asrsett ntype: NTASRS. This entry is present only
on a SPARC V9 machine and only if the process
is a 64-bit process. It contains the ancil-
lary state registers for the LWP. The
asrsett structure is defined in
.
Depending on the coreadm(1M) settings, the section header of
an ELF core file can contain entries for CTF, symbol table,
and string table sections. The shaddr fields are set to the
base address of the first mapping of the load object that
they came from to. This can be used to match those sections
with the corresponding load object.
The size of the core file created by a process can be con-
trolled by the user (see getrlimit(2)).
SEE ALSO
elfdump(1), gcore(1), mdb(1), proc(1), ps(1), coreadm(1M),
getrlimit(2), setrlimit(2), setuid(2), sysinfo(2), uname(2),
getzonenamebyid(3C), getzoneid(3C), elf(3ELF),
signal.h(3HEAD), a.out(4), proc(4), zones(5)
ANSI C Programmer's Guide
SunOS 5.11 Last change: 13 May 2008 7
|
