1core(4) File Formats core(4)
2
6 core - process core file
7
9 The operating system writes out a core file for a process when the
10 process is terminated due to receiving certain signals. A core file is
11 a disk copy of the contents of the process address space at the time
12 the process received the signal, along with additional information
13 about the state of the process. This information can be consumed by a
14 debugger. Core files can also be generated by applying the gcore(1)
15 utility to a running process.
16 Typically, core files are produced following abnormal termination of a
19 process resulting from a bug in the corresponding application. Whatever
20 the cause, the core file itself provides invaluable information to the
21 programmer or support engineer to aid in diagnosing the problem. The
22 core file can be inspected using a debugger such as dbx(1) or mdb(1) or
23 by applying one of the proc(1) tools.
24 The operating system attempts to create up to two core files for each
27 abnormally terminating process, using a global core file name pattern
28 and a per-process core file name pattern. These patterns are expanded
29 to determine the pathname of the resulting core files, and can be con‐
30 figured by coreadm(1M). By default, the global core file pattern is
31 disabled and not used, and the per-process core file pattern is set to
32 core. Therefore, by default, the operating system attempts to create a
33 core file named core in the process's current working directory.
34 A process terminates and produces a core file whenever it receives one
37 of the signals whose default disposition is to cause a core dump. The
38 list of signals that result in generating a core file is shown in sig‐
39 nal.h(3HEAD). Therefore, a process might not produce a core file if it
40 has blocked or modified the behavior of the corresponding signal. Addi‐
41 tionally, no core dump can be created under the following conditions:
42 o If normal file and directory access permissions prevent the
44 creation or modification of the per-process core file path‐
45 name by the current process user and group ID. This test
46 does not apply to the global core file pathname because,
47 regardless of the UID of the process dumping core, the
48 attempt to write the global core file is made as the supe‐
49 ruser.
50 o Core files owned by the user nobody will not be produced.
52 For example, core files generated for the superuser on an
53 NFS directory are owned by nobody and are, therefore, not
54 written.
55 o If the core file pattern expands to a pathname that contains
57 intermediate directory components that do not exist. For
58 example, if the global pattern is set to
59 /var/core/%n/core.%p, and no directory /var/core/`uname -n`
60 has been created, no global core files are produced.
61 o If the destination directory is part of a filesystem that is
63 mounted read-only.
64 o If the resource limit RLIMIT_CORE has been set to 0 for the
66 process, no per-process core file is produced. Refer to
67 setrlimit(2) and ulimit(1) for more information on resource
68 limits.
69 o If the core file name already exists in the destination
71 directory and is not a regular file (that is, is a symlink,
72 block or character special-file, and so forth).
73 o If the kernel cannot open the destination file O_EXCL, which
75 can occur if same file is being created by another process
76 simultaneously.
77 o If the process's effective user ID is different from its
79 real user ID or if its effective group ID is different from
80 its real group ID. Similarly, set-user-ID and set-group-ID
81 programs do not produce core files as this could potentially
82 compromise system security. These processes can be explic‐
83 itly granted permission to produce core files using core‐
84 adm(1M), at the risk of exposing secure information.
85 The core file contains all the process information pertinent to debug‐
88 ging: contents of hardware registers, process status, and process data.
89 The format of a core file is object file specific.
90 For ELF executable programs (see a.out(4)), the core file generated is
93 also an ELF file, containing ELF program and file headers. The e_type
94 field in the file header has type ET_CORE. The program header contains
95 an entry for every segment that was part of the process address space,
96 including shared library segments. The contents of the mappings speci‐
97 fied by coreadm(1M) are also part of the core image. Each program
98 header has its p_memsz field set to the size of the mapping. The pro‐
99 gram headers that represent mappings whose data is included in the core
100 file have their p_filesz field set the same as p_memsz, otherwise
101 p_filesz is zero.
102 A mapping's data can be excluded due to the core file content settings
105 (see coreadm(1M)), or due to some failure. If the data is excluded
106 because of a failure, the program header entry will have the
107 PF_SUNW_FAILURE flag set in its p_flags field.
108 The program headers of an ELF core file also contain entries for two
111 NOTE segments, each containing several note entries as described below.
112 The note entry header and core file note type (n_type) definitions are
113 contained in <sys/elf.h>. The first NOTE segment exists for binary com‐
114 patibility with old programs that deal with core files. It contains
115 structures defined in <sys/old_procfs.h>. New programs should recognize
116 and skip this NOTE segment, advancing instead to the new NOTE segment.
117 The old NOTE segment is deleted from core files in a future release.
118 The old NOTE segment contains the following entries. Each has entry
121 name "CORE" and presents the contents of a system structure:
122 prpsinfo_t n_type: NT_PRPSINFO. This entry contains information of
124 interest to the ps(1) command, such as process status,
125 CPU usage, nice value, controlling terminal, user-ID,
126 process-ID, the name of the executable, and so forth.
127 The prpsinfo_t structure is defined in
128 <sys/old_procfs.h>.
129 char array n_type: NT_PLATFORM. This entry contains a string
132 describing the specific model of the hardware platform
133 on which this core file was created. This information
134 is the same as provided by sysinfo(2) when invoked with
135 the command SI_PLATFORM.
136 auxv_t array n_type: NT_AUXV. This entry contains the array of
139 auxv_t structures that was passed by the operating sys‐
140 tem as startup information to the dynamic linker. Aux‐
141 iliary vector information is defined in <sys/auxv.h>.
142 Following these entries, for each active (non-zombie) light-weight
146 process (LWP) in the process, the old NOTE segment contains an entry
147 with a prstatus_t structure, plus other optionally-present entries
148 describing the LWP, as follows:
149 prstatus_t n_type: NT_PRSTATUS. This structure contains things of
151 interest to a debugger from the operating system, such
152 as the general registers, signal dispositions, state,
153 reason for stopping, process-ID, and so forth. The
154 prstatus_t structure is defined in <sys/old_procfs.h>.
155 prfpregset_t n_type: NT_PRFPREG. This entry is present only if the
158 LWP used the floating-point hardware. It contains the
159 floating-point registers. The prfpregset_t structure is
160 defined in <sys/procfs_isa.h>.
161 gwindows_t n_type: NT_GWINDOWS. This entry is present only on a
164 SPARC machine and only if the system was unable to
165 flush all of the register windows to the stack. It con‐
166 tains all of the unspilled register windows. The gwin‐
167 dows_t structure is defined in <sys/regset.h>.
168 prxregset_t n_type: NT_PRXREG. This entry is present only if the
171 machine has extra register state associated with it. It
172 contains the extra register state. The prxregset_t
173 structure is defined in <sys/procfs_isa.h>.
174 The new NOTE segment contains the following entries. Each has entry
178 name "CORE" and presents the contents of a system structure:
179 psinfo_t n_type: NT_PSINFO. This structure contains informa‐
181 tion of interest to the ps(1) command, such as
182 process status, CPU usage, nice value, controlling
183 terminal, user-ID, process-ID, the name of the exe‐
184 cutable, and so forth. The psinfo_t structure is
185 defined in <sys/procfs.h>.
186 pstatus_t n_type: NT_PSTATUS. This structure contains things
189 of interest to a debugger from the operating sys‐
190 tem, such as pending signals, state, process-ID,
191 and so forth. The pstatus_t structure is defined in
192 <sys/procfs.h>.
193 char array n_type: NT_PLATFORM. This entry contains a string
196 describing the specific model of the hardware plat‐
197 form on which this core file was created. This
198 information is the same as provided by sysinfo(2)
199 when invoked with the command SI_PLATFORM.
200 auxv_t array n_type: NT_AUXV. This entry contains the array of
203 auxv_t structures that was passed by the operating
204 system as startup information to the dynamic
205 linker. Auxiliary vector information is defined in
206 <sys/auxv.h>.
207 struct utsname n_type: NT_UTSNAME. This structure contains the
210 system information that would have been returned to
211 the process if it had performed a uname(2) system
212 call prior to dumping core. The utsname structure
213 is defined in <sys/utsname.h>.
214 prcred_t n_type: NT_PRCRED. This structure contains the
217 process credentials, including the real, saved, and
218 effective user and group IDs. The prcred_t struc‐
219 ture is defined in <aasys/procfs.h>. Following the
220 structure is an optional array of supplementary
221 group IDs. The total number of supplementary group
222 IDs is given by the pr_ngroups member of the
223 prcred_t structure, and the structure includes
224 space for one supplementary group. If pr_ngroups is
225 greater than 1, there is pr_ngroups - 1 gid_t items
226 following the structure; otherwise, there is no
227 additional data.
228 char array n_type: NT_ZONENAME. This entry contains a string
231 which describes the name of the zone in which the
232 process was running. See zones(5). The information
233 is the same as provided by getzonenamebyid(3C) when
234 invoked with the numerical ID returned by get‐
235 zoneid(3C).
236 struct ssd array n_type: NT_LDT. This entry is present only on an
239 32-bit x86 machine and only if the process has set
240 up a Local Descriptor Table (LDT). It contains an
241 array of structures of type struct ssd, each of
242 which was typically used to set up the %gs segment
243 register to be used to fetch the address of the
244 current thread information structure in a multi‐
245 threaded process. The ssd structure is defined in
246 <sys/sysi86.h>.
247 core_content_t n_type: NT_CONTENT. This optional entry indicates
250 which parts of the process image are specified to
251 be included in the core file. See coreadm(1M).
252 Following these entries, for each active and zombie LWP in the process,
256 the new NOTE segment contains an entry with an lwpsinfo_t structure
257 plus, for a non-zombie LWP, an entry with an lwpstatus_t structure,
258 plus other optionally-present entries describing the LWP, as follows. A
259 zombie LWP is a non-detached LWP that has terminated but has not yet
260 been reaped by another LWP in the same process.
261 lwpsinfo_t n_type: NT_LWPSINFO. This structure contains information
263 of interest to the ps(1) command, such as LWP status,
264 CPU usage, nice value, LWP-ID, and so forth. The
265 lwpsinfo_t structure is defined in <sys/procfs.h>. This
266 is the only entry present for a zombie LWP.
267 lwpstatus_t n_type: NT_LWPSTATUS. This structure contains things of
270 interest to a debugger from the operating system, such
271 as the general registers, the floating point registers,
272 state, reason for stopping, LWP-ID, and so forth. The
273 lwpstatus_t structure is defined in <sys/procfs.h>>.
274 gwindows_t n_type: NT_GWINDOWS. This entry is present only on a
277 SPARC machine and only if the system was unable to flush
278 all of the register windows to the stack. It contains
279 all of the unspilled register windows. The gwindows_t
280 structure is defined in <sys/regset.h>.
281 prxregset_t n_type: NT_PRXREG. This entry is present only if the
284 machine has extra register state associated with it. It
285 contains the extra register state. The prxregset_t
286 structure is defined in <sys/procfs_isa.h>.
287 asrset_t n_type: NT_ASRS. This entry is present only on a SPARC
290 V9 machine and only if the process is a 64-bit process.
291 It contains the ancillary state registers for the LWP.
292 The asrset_t structure is defined in <sys/regset.h>.
293 Depending on the coreadm(1M) settings, the section header of an ELF
297 core file can contain entries for CTF, symbol table, and string table
298 sections. The sh_addr fields are set to the base address of the first
299 mapping of the load object that they came from to. This can be used to
300 match those sections with the corresponding load object.
301 The size of the core file created by a process can be controlled by the
304 user (see getrlimit(2)).
305
307 elfdump(1), gcore(1), mdb(1), proc(1), ps(1), coreadm(1M), getr‐
308 limit(2), setrlimit(2), setuid(2), sysinfo(2), uname(2), getzonename‐
309 byid(3C), getzoneid(3C), elf(3ELF), signal.h(3HEAD), a.out(4), proc(4),
310 zones(5)
311 ANSI C Programmer's Guide
314SunOS 5.11 13 May 2008 core(4)