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:
-s
-v
-b
size-x
contentstack
compact
full
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:
-o
path-c
pathformatEach special character is introduced by the
%
character. The format characters and their
meanings are:
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.
The gcore
utility exits 0 on
success, and >0 if an error occurs.
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 |