In computing, a core dump (in Unix parlance), memory dump, or system dump[1] consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has terminated abnormally (crashed).[2] In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. Core dumps are often used to assist in diagnosing and debugging errors in computer programs.
The name comes from magnetic core memory,[3] the principal form of random access memory from the 1950s to the 1970s. The name has remained long after magnetic core technology became obsolete.
On many operating systems, a fatal error in a program automatically triggers a core dump; by extension the phrase "to dump core" has come to mean, in many cases, any fatal error, regardless of whether a record of the program memory results.
The term "core dump", "memory dump", or just "dump" has become jargon to indicate any storing of a large amount of raw data for further examination.
Contents |
Background[edit]
Before the advent of disk operating systems and the ability to record large data file, core dumps were paper printouts[4] of the contents of memory, typically arranged in columns of octal or hexadecimal numbers (a "hex dump"), sometimes accompanied by their interpretations as machine language instructions, text strings, or decimal or floating-point numbers (cf. disassembler). In more recent operating systems, a "core dump" is a file containing the memory image of a particular process, or the memory images of parts of the address space of that process, along with other information such as the values of processor registers. These files can be printed or viewed as text, or analysed with specialised tools such as objdump.
Uses of core dumps[edit]
Core dumps can serve as useful debugging aids in several situations. On early standalone or batch-processing systems, core dumps allowed a user to debug a program without monopolizing the (very expensive) computing facility for debugging; a printout could also be more convenient than debugging using switches and lights. On shared computers, whether time-sharing, batch processing, or server systems, core dumps allow off-line debugging of the operating system, so that the system can go back into operation immediately. Core dumps allow a user to save a crash for later or off-site analysis, or comparison with other crashes. For embedded computers, it may be impractical to support debugging on the computer itself, so analysis of a dump may take place on a different computer. Some operating systems such as early versions of Unix did not support attaching debuggers to running processes, so core dumps were necessary to run a debugger on a process's memory contents. Core dumps can be used to capture data freed during dynamic memory allocation and may thus be used to retrieve information from a program that is no longer running. In the absence of an interactive debugger, the core dump may be used by an assiduous programmer to determine the error from direct examination.
A core dump represents the complete contents of the dumped regions of the address space of the dumped process. Depending on the operating system, the dump may contain few or no data structures to aid interpretation of the memory regions. In these systems, successful interpretation requires that the program or user trying to interpret the dump understands the structure of the program's memory use.
A debugger can use a symbol table, if one exists, to help the programmer interpret dumps, identifying variables symbolically and displaying source code; if the symbol table is not available, less interpretation of the dump is possible, but there might still be enough possible to determine the cause of the problem. There are also special-purpose tools called dump analyzers to analyze dumps. One popular tool, available on many operating systems, is the GNU binutils' objdump.
On modern Unix-like operating systems, administrators and programmers can read core dump files using the GNU Binutils Binary File Descriptor library (BFD), and the GNU Debugger (gdb) and objdump that use this library. This library will supply the raw data for a given address in a memory region from a core dump; it does not know anything about variables or data structures in that memory region, so the application using the library to read the core dump will have to determine the addresses of variables and determine the layout of data structures itself, for example by using the symbol table for the program undergoing debugging.
Analysts of crash dumps from Linux systems can use kdump or the Linux Kernel Crash Dump (LKCD).[5]
Core dumps can save the context (state) of a process at a given state for returning to it later. Systems can be made highly available by transferring core between processors, sometimes via core dump files themselves.
Core can also be dumped onto a remote host over a network (which is a security risk).[6]
Core dump files[edit]
Format[edit]
In older and simpler operating systems, each process had a contiguous address-space, so a core dump file was simply a binary file with the sequence of bytes or words. In modern operating systems, a process address space may have gaps, and share pages with other processes or files, so more elaborate representations are used; they may also include other information about the state of the program at the time of the dump.
In Unix-like systems, core dumps generally use the standard executable image-format:
- a.out in older versions of Unix,
- ELF in modern Linux, System V, Solaris, and BSD systems,
- Mach-O in OS X, etc.
Naming[edit]
- Dumps of user-processes traditionally get created as "
core". - System-wide dumps on modern Unix-like systems often appear as "
vmcore" or as "vmcore.incomplete". - Systems such as Microsoft Windows which use filename extensions may use the extension "
.dmp", e.g., "memory.dmp" or "\Minidump\Mini051509-01.dmp".
Windows Memory Dumps[edit]
Windows supports various memory dump formats:[7]
- Kernel-mode dumps
- Complete Memory Dump - contains full physical memory for the target system.
- Kernel Memory Dump - contains all the memory in use by the kernel at the time of the crash.
- Small Memory Dump - contains various info such as the stop code, parameters, list of loaded device drivers, etc.
- User-mode memory dumps
- Full User-Mode Dumps - includes the entire memory space of a process
- Minidumps - includes only selected parts of the memory associated with a process.
See also[edit]
References[edit]
- ^ "AIX 7.1 information".
- ^ : Process core file – Solaris 10 File Formats Reference Manual
- ^ Oxford English Dictionary, s.v. 'core'
- ^ "storage dump definition".
- ^ Venkateswaran, Sreekrishnan (2008). Essential Linux device drivers. Prentice Hall open source software development series. Prentice Hall. p. 623. ISBN 978-0-13-239655-4. Retrieved 2010-07-15. "Until the advent of kdump, Linux Kernel Crash Dump (LKCD) was the popular mechanism to obtain and analyze dumps."
- ^ Fedora Documentation Project (2010). Fedora 13 Security Guide. Fultus Corporation. p. 63. ISBN 978-1-59682-214-6. Retrieved 2010-09-29. "Remote memory dump services, like
netdump, transmit the contents of memory over the network unencrypted." - ^ Windows Memory Dump Types
External links[edit]
Descriptions for the file format:
- – Linux Programmer's Manual – File Formats
- – Solaris 10 File Formats Reference Manual
- – HP-UX 11i File Formats Manual
- – FreeBSD File Formats Manual
- – OpenBSD File Formats Manual
- – NetBSD File Formats Manual
- – Darwin and Mac OS X File Formats Manual
- Enabling core dumps in embedded systems - An article from the Real-Time embedded blog
- Minidump Files.
Kernel core dumps:
A portion of the proceeds from advertising on Digplanet goes to supporting Wikipedia.
