GCORE(1) General Commands Manual GCORE(1)

gcore — get core images of running processes

gcore [-v] [-s] [-b size] [-x content] [-o path | -c pathformat] pid

The gcore program creates a core file image of the process specified by pid. The resulting core file can be used with a debugger, e.g. lldb(1), to examine the state of the process.

The following options are available:

Suspend the process while the core file is captured.
Report progress on the dump as it proceeds.
size
Limit the size of the core file to size MiBytes.
content
Select the content type of process pages written to the core file. The currently supported content types are:
Only include pages containing stack regions.
Only include pages that were modified during execution.
All accessible pages in the process.

The full content option is the default, and may lead to the creation of very large core files. The stack content type can be useful to examine low-level thread stacks. The resulting core file is small, but the amount of debugging information that is available is correspondingly limited. The compact content setting produces core files that are usually smaller than the full option.

The following options control the name of the core file:

path
Write the core file to path.
pathformat
Write the core file to pathformat. The pathformat string is treated as a pathname that may contain various special characters which cause the interpolation of strings representing specific attributes of the process into the name.

Each special character is introduced by the % character. The format characters and their meanings are:

The name of the program being dumped, as reported by ps(1).
The uid of the process being dumped, converted to a string.
The pid of the process being dumped, converted to a string.
The time when the core file was taken, converted to ISO 8601 format.
Output a percent character.

The default file name used by gcore is %N-%P-%T. By default, the core file will be written to a directory whose name is determined from the kern.corefile MIB. This can be printed or modified using sysctl(8).

The directory where the core file is to be written must be accessible to the owner of the target process.

gcore will not overwrite an existing file, nor will it create missing directories in the path.

/cores/%N-%P-%T
default pathname for the corefile.

The gcore utility exits 0 on success, and >0 if an error occurs.

lldb(1), otool(1), core(5), Mach-O(5), sudo(8), sysctl(8)

By default, gcore uses a copy-on-write address space snapshot to dump a process, minimizing the time that the process is unable to respond to external events. However, these snapshots are a limited resource, and if it cannot be taken, gcore will revert to the historical behavior of gcore i.e. it will capture the state of the process without suspending its execution, which may result in an inconsistent state being saved to the resulting core file. Use the -s flag if this is a concern.

For both stack and compact content options it is important to realize that the resulting core file is reduced in size because it implicitly refers to the contents of the application together with its library and framework dependencies that were present on the system at the specific point in time that the dump was taken. As a result, such core files are most useful when debugging applications on the same system that they were captured on. Attempting to use those core files for debugging on a different platform, or after any of the components have been updated, may make productive debugging far more difficult.

November 21, 2024 Darwin