core(4)core(4)NAMEcore - format of core image file
The HP-UX system writes out a file containing a core image of a termi‐
nated process when certain signals are received (see signal(5) for the
list of reasons). The most common causes are memory violations, ille‐
gal instructions, floating point exceptions, bus errors, and user-gen‐
erated quit signals. The core image file is called and is written in
the process's working directory (provided it is allowed by normal
access controls). A process with an effective user ID different from
its real user ID does not produce a core image.
The file contains sufficient information to determine what the process
was doing at the time of its termination. Core file contents consist
of objects that represent different segments of a process. Each object
is preceded by a data structure, and each data structure describes the
corresponding object following it. The structure is defined in and
includes the following members:
The space and addr members specify the virtual memory address in the
process where the described object began. The len member is the length
of the object in bytes.
The following possible values for type are defined in
Process data as it existed at the time the core image was cre‐
This includes initialized data, uninitialized
data, and the heap at the time the core image
A compiler-dependent data structure containing the exec data
the magic number of the executable file, and
the command (see the declaration of the struc‐
The version number of the core format produced.
This number changes with each HP-UX release
where the core format itself has changed.
However, it does not necessarily change with
every HP-UX release. can thus be easily used
by core-reading tools to determine whether
they are compatible with a given core image.
This type is expressed by a four-byte binary
The null-terminated version string associated with the kernel
at the time the core image was generated.
An architecture-dependent data structure
containing per-process information such as
hardware register contents. See the declara‐
tion of the structure in
Process stack contents at the time the core image was created.
Objects dumped in a image file are not arranged in any particular
order. Use information to determine the type of the object that imme‐
diately follows it.
SEE ALSOadb(1), coreadm(1M), coreadm(2), setuid(2), crt0(3), end(3C), sig‐