Windows PowerShell command on Get-command core

Manual Pages for UNIX Operating System command usage for man core

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 RLIMIT_CORE 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

O_EXCL, 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 e_type field in the file header has type

ET_CORE. 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 p_memsz field set to the size of

the mapping. The program headers that represent mappings

whose data is included in the core file have their p_filesz

field set the same as p_memsz, otherwise p_filesz 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 PF_SUNW_FAILURE flag set in its

p_flags 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 (n_type) 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:

prpsinfo_t n_type: NT_PRPSINFO. 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 prpsinfo_t structure is

defined in .

char array n_type: NT_PLATFORM. 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 SI_PLATFORM.

auxv_t array n_type: NT_AUXV. This entry contains the

array of auxv_t 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 prstatus_t structure, plus

other optionally-present entries describing the LWP, as fol-

lows:

prstatus_t n_type: NT_PRSTATUS. 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

prstatus_t structure is defined in

prfpregset_t n_type: NT_PRFPREG. This entry is present

only if the LWP used the floating-point

hardware. It contains the floating-point

registers. The prfpregset_t structure is

defined in .

gwindows_t n_type: NT_GWINDOWS. 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 gwindows_t

structure is defined in .

prxregset_t n_type: NT_PRXREG. This entry is present

only if the machine has extra register state associated with it. It contains the extra

defined in .

The new NOTE segment contains the following entries. Each has entry name "CORE" and presents the contents of a system structure:

psinfo_t n_type: NT_PSINFO. 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

psinfo_t structure is defined in

SunOS 5.11 Last change: 13 May 2008 4

File Formats core(4)

pstatus_t n_type: NT_PSTATUS. 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 pstatus_t structure is

defined in .

char array n_type: NT_PLATFORM. 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

SI_PLATFORM.

auxv_t array n_type: NT_AUXV. This entry contains the

array of auxv_t structures that was

passed by the operating system as startup information to the dynamic linker. Auxiliary vector information is defined in .

struct utsname n_type: NT_UTSNAME. 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 .

prcred_t n_type: NT_PRCRED. This structure con-

tains the process credentials, including the real, saved, and effective user and

group IDs. The prcred_t 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 pr_ngroups member of the

prcred_t structure, and the structure

includes space for one supplementary

group. If pr_ngroups is greater than 1,

there is pr_ngroups - 1 gid_t items fol-

lowing the structure; otherwise, there is no additional data.

char array n_type: NT_ZONENAME. 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 n_type: NT_LDT. 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 .

core_content_t n_type: NT_CONTENT. 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

lwpsinfo_t structure plus, for a non-zombie LWP, an entry

with an lwpstatus_t 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.

lwpsinfo_t n_type: NT_LWPSINFO. 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 lwpsinfo_t struc-

ture is defined in . This is the only entry present for a zombie LWP.

lwpstatus_t n_type: NT_LWPSTATUS. 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 lwpstatus_t structure is defined in

SunOS 5.11 Last change: 13 May 2008 6

File Formats core(4)

gwindows_t n_type: NT_GWINDOWS. 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 gwindows_t

structure is defined in .

prxregset_t n_type: NT_PRXREG. This entry is present only

if the machine has extra register state asso-

ciated with it. It contains the extra regis-

ter state. The prxregset_t structure is

defined in .

asrset_t n_type: NT_ASRS. 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

asrset_t 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 sh_addr 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)).

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

Manual Pages for UNIX Operating System command usage for man core

File Formats core(4)

NAME

core - process core file

DESCRIPTION

The operating system writes out a core file for a process

nals. A core file is a disk copy of the contents of the pro-

Core files can also be generated by applying the gcore(1)

Typically, core files are produced following abnormal termi-

ing application. Whatever the cause, the core file itself

engineer to aid in diagnosing the problem. The core file can

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.

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.

create a core file named core in the process's current work-

A process terminates and produces a core file whenever it

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

ally, no core dump can be created under the following condi-

process core file pathname by the current process

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

File Formats core(4)

produced. For example, core files generated for the

o If the core file pattern expands to a pathname that

set to /var/core/%n/core.%p, and no directory

/var/core/`uname -n` has been created, no global

core files are produced.

for the process, no per-process core file is pro-

o If the core file name already exists in the desti-

duce core files as this could potentially comprom-

citly granted permission to produce core files

using coreadm(1M), at the risk of exposing secure

The core file contains all the process information pertinent

status, and process data. The format of a core file is

For ELF executable programs (see a.out(4)), the core file

File Formats core(4)

specified by coreadm(1M) are also part of the core image.

whose data is included in the core file have their p_filesz

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 program headers of an ELF core file also contain entries

as described below. The note entry header and core file note

programs that deal with core files. It contains structures

NOTE segment. The old NOTE segment is deleted from core

hardware platform on which this core file

File Formats core(4)

File Formats core(4)

core file was created. This information

struct utsname n_type: NT_UTSNAME. This structure con-

prior to dumping core. The utsname

char array n_type: NT_ZONENAME. This entry contains

File Formats core(4)

core_content_t n_type: NT_CONTENT. This optional entry

the core file. See coreadm(1M).

File Formats core(4)

Depending on the coreadm(1M) settings, the section header of

an ELF core file can contain entries for CTF, symbol table,

The size of the core file created by a process can be con-

SEE ALSO

elfdump(1), gcore(1), mdb(1), proc(1), ps(1), coreadm(1M),