CORE(4) File Formats and Configurations CORE(4) NNAAMMEE core - process core file DDEESSCCRRIIPPTTIIOONN The operating system writes out a core file for a process when the process is terminated due to receiving certain signals. A core file is a disk copy of the contents of the process address space at the time the process received the signal, 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 ggccoorree(1) utility to a running process. Typically, core files are produced following abnormal termination of a process resulting from a bug in the corresponding 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 ddbbxx(1) or mmddbb(1) or by applying one of the pprroocc(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 ccoorreeaaddmm(1M). By default, the global core file pattern is disabled and not used, and the per-process core file pattern is set to ccoorree. Therefore, by default, the operating system attempts to create a core file named ccoorree in the process's current working 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 generating a core file is shown in ssiiggnnaall..hh(3HEAD). Therefore, a process might not produce a core file if it has blocked or modified the behavior of the corresponding signal. Additionally, no core dump can be created under the following conditions: 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. o Core files owned by the user nnoobbooddyy will not be produced. For example, core files generated for the superuser on an NFS directory are owned by nnoobbooddyy 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 //vvaarr//ccoorree//%%nn//ccoorree..%%pp, and no directory //vvaarr//ccoorree//``uunnaammee --nn`` has been created, no global core files are produced. o If the destination directory is part of a filesystem that is mounted read-only. o If the resource limit RRLLIIMMIITT__CCOORREE has been set to 00 for the process, no per-process core file is produced. Refer to sseettrrlliimmiitt(2) and uulliimmiitt(1) for more information on resource limits. o If the core file name already exists in the destination 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 OO__EEXXCCLL, 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 produce core files as this could potentially compromise system security. These processes can be explicitly granted permission to produce core files using ccoorreeaaddmm(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 aa..oouutt(4)), the core file generated is also an ELF file, containing ELF program and file headers. The ee__ttyyppee field in the file header has type EETT__CCOORREE. The program header contains an entry for every segment that was part of the process address space, including shared library segments. The contents of the mappings specified by ccoorreeaaddmm(1M) are also part of the core image. Each program header has its pp__mmeemmsszz field set to the size of the mapping. The program headers that represent mappings whose data is included in the core file have their pp__ffiilleesszz field set the same as pp__mmeemmsszz, otherwise pp__ffiilleesszz is zzeerroo. A mapping's data can be excluded due to the core file content settings (see ccoorreeaaddmm(1M)), due to a failure, or due to a signal received after core dump initiation but before its completion. If the data is excluded because of a failure, the program header entry will have the PPFF__SSUUNNWW__FFAAIILLUURREE flag set in its pp__ffllaaggss field; if the data is excluded because of a signal, the segment's pp__ffllaaggss field will have the PPFF__SSUUNNWW__KKIILLLLEEDD flag set. The program headers of an EELLFF core file also contain entries for two NNOOTTEE segments, each containing several note entries as described below. The note entry header and core file note type (nn__ttyyppee) definitions are contained in . The first NNOOTTEE 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 NNOOTTEE segment, advancing instead to the new NNOOTTEE segment. The old NNOOTTEE segment is deleted from core files in a future release. The old NNOOTTEE segment contains the following entries. Each has entry name ""CCOORREE"" and presents the contents of a system structure: pprrppssiinnffoo__tt nn__ttyyppee: NNTT__PPRRPPSSIINNFFOO. This entry contains information of interest to the ppss(1) command, such as process status, CCPPUU usage, nniiccee value, controlling terminal, user-ID, process-ID, the name of the executable, and so forth. The pprrppssiinnffoo__tt structure is defined in . cchhaarr array nn__ttyyppee: NNTT__PPLLAATTFFOORRMM. 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 ssyyssiinnffoo(2) when invoked with the command SSII__PPLLAATTFFOORRMM. aauuxxvv__tt array nn__ttyyppee: NNTT__AAUUXXVV. This entry contains the array of aauuxxvv__tt structures that was passed by the operating system as startup information to the dynamic linker. Auxiliary vector information is defined in . Following these entries, for each active (non-zombie) light-weight process (LWP) in the process, the old NNOOTTEE segment contains an entry with a pprrssttaattuuss__tt structure, plus other optionally-present entries describing the LWP, as follows: pprrssttaattuuss__tt nn__ttyyppee: NNTT__PPRRSSTTAATTUUSS. This structure contains things of interest to a debugger from the operating system, such as the general registers, signal dispositions, state, reason for stopping, process-ID, and so forth. The pprrssttaattuuss__tt structure is defined in . pprrffpprreeggsseett__tt nn__ttyyppee: NNTT__PPRRFFPPRREEGG. This entry is present only if the LLWWPP used the floating-point hardware. It contains the floating-point registers. The pprrffpprreeggsseett__tt structure is defined in . ggwwiinnddoowwss__tt nn__ttyyppee: NNTT__GGWWIINNDDOOWWSS. This entry is present only on a SPARC machine and only if the system was unable to flush all of the register windows to the stack. It contains all of the unspilled register windows. The ggwwiinnddoowwss__tt structure is defined in . pprrxxrreeggsseett__tt nn__ttyyppee: NNTT__PPRRXXRREEGG. This entry is present only if the machine has extra register state associated with it. It contains the extra register state. The pprrxxrreeggsseett__tt structure is defined in . The new NNOOTTEE segment contains the following entries. Each has entry name "CCOORREE" and presents the contents of a system structure: ppssiinnffoo__tt nn__ttyyppee: NNTT__PPSSIINNFFOO. This structure contains information of interest to the ppss(1) command, such as process status, CCPPUU usage, nniiccee value, controlling terminal, user-ID, process-ID, the name of the executable, and so forth. The ppssiinnffoo__tt structure is defined in . ppssttaattuuss__tt nn__ttyyppee: NNTT__PPSSTTAATTUUSS. This structure contains things of interest to a debugger from the operating system, such as pending signals, state, process-ID, and so forth. The ppssttaattuuss__tt structure is defined in . cchhaarr array nn__ttyyppee: NNTT__PPLLAATTFFOORRMM. 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 ssyyssiinnffoo(2) when invoked with the command SSII__PPLLAATTFFOORRMM. aauuxxvv__tt array nn__ttyyppee: NNTT__AAUUXXVV. This entry contains the array of aauuxxvv__tt structures that was passed by the operating system as startup information to the dynamic linker. Auxiliary vector information is defined in . ssttrruucctt uuttssnnaammee nn__ttyyppee: NNTT__UUTTSSNNAAMMEE. This structure contains the system information that would have been returned to the process if it had performed a uunnaammee(2) system call prior to dumping core. The uuttssnnaammee structure is defined in . pprrccrreedd__tt nn__ttyyppee: NNTT__PPRRCCRREEDD. This structure contains the process credentials, including the real, saved, and effective user and group IDs. The pprrccrreedd__tt 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 pprr__nnggrroouuppss member of the pprrccrreedd__tt structure, and the structure includes space for one supplementary group. If pprr__nnggrroouuppss is greater than 1, there is pprr__nnggrroouuppss -- 11 ggiidd__tt items following the structure; otherwise, there is no additional data. cchhaarr aarrrraayy nn__ttyyppee: NNTT__ZZOONNEENNAAMMEE. This entry contains a string which describes the name of the zone in which the process was running. See zzoonneess(5). The information is the same as provided by ggeettzzoonneennaammeebbyyiidd(3C) when invoked with the numerical ID returned by ggeettzzoonneeiidd(3C). pprrffddiinnffoo__tt nn__ttyyppee: NNTT__FFDDIINNFFOO. This structure contains information about any open file descriptors, including the path, flags, and ssttaatt(2) information. The pprrffddiinnffoo__tt structure is defined in . ssttrruucctt ssssdd array nn__ttyyppee: NNTT__LLDDTT. 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 ssttrruucctt ssssdd, each of which was typically used to set up the %%ggss segment register to be used to fetch the address of the current thread information structure in a multithreaded process. The ssssdd structure is defined in . ccoorree__ccoonntteenntt__tt nn__ttyyppee: NNTT__CCOONNTTEENNTT. This optional entry indicates which parts of the process image are specified to be included in the core file. See ccoorreeaaddmm(1M). Following these entries, for each active and zombie LLWWPP in the process, the new NNOOTTEE segment contains an entry with an llwwppssiinnffoo__tt structure plus, for a non-zombie LWP, an entry with an llwwppssttaattuuss__tt 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. llwwppssiinnffoo__tt nn__ttyyppee: NNTT__LLWWPPSSIINNFFOO. This structure contains information of interest to the ppss(1) command, such as LLWWPP status, CCPPUU usage, nniiccee value, LLWWPP--IIDD, and so forth. The llwwppssiinnffoo__tt structure is defined in . This is the only entry present for a zombie LWP. llwwppssttaattuuss__tt nn__ttyyppee: NNTT__LLWWPPSSTTAATTUUSS. This structure contains things of interest to a debugger from the operating system, such as the general registers, the floating point registers, state, reason for stopping, LLWWPP--IIDD, and so forth. The llwwppssttaattuuss__tt structure is defined in >>. ggwwiinnddoowwss__tt nn__ttyyppee: NNTT__GGWWIINNDDOOWWSS. This entry is present only on a SPARC machine and only if the system was unable to flush all of the register windows to the stack. It contains all of the unspilled register windows. The ggwwiinnddoowwss__tt structure is defined in <>. pprrxxrreeggsseett__tt nn__ttyyppee: NNTT__PPRRXXRREEGG. This entry is present only if the machine has extra register state associated with it. It contains the extra register state. The pprrxxrreeggsseett__tt structure is defined in <>. aassrrsseett__tt nn__ttyyppee: NNTT__AASSRRSS. This entry is present only on a SPARC V9 machine and only if the process is a 64-bit process. It contains the ancillary state registers for the LLWWPP.. The aassrrsseett__tt structure is defined in <>. ppssiinnffoo__tt nn__ttyyppee: NNTT__SSPPYYMMAASSTTEERR. This entry is present only for an agent LWP and contains the ppssiinnffoo__tt of the process that created the agent LWP. See the pprroocc(4) description of the ssppyymmaasstteerr entry for more details. pprrsseeccffllaaggss__tt nn__ttyyppee: NT_SECFLAGS. This entry contains the process security-flags, see sseeccuurriittyy--ffllaaggss(5), pprroocc(4), and ppsseeccffllaaggss(1M) for more information. Depending on the ccoorreeaaddmm(1M) settings, the section header of an ELF core file can contain entries for CTF, symbol table, and string table sections. The sshh__aaddddrr 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 controlled by the user (see ggeettrrlliimmiitt(2)). SSEEEE AALLSSOO eellffdduummpp(1), ggccoorree(1), mmddbb(1), pprroocc(1), ppss(1), ccoorreeaaddmm(1M), ggeettrrlliimmiitt(2), sseettrrlliimmiitt(2), sseettuuiidd(2), ssyyssiinnffoo(2), uunnaammee(2), ggeettzzoonneennaammeebbyyiidd(3C), ggeettzzoonneeiidd(3C), eellff(3ELF), ssiiggnnaall..hh(3HEAD), aa..oouutt(4), pprroocc(4), zzoonneess(5), sseeccuurriittyy--ffllaaggss(5) _A_N_S_I _C _P_r_o_g_r_a_m_m_e_r_'_s _G_u_i_d_e June 6, 2016 CORE(4)