In Star Trek, refers to a procedure in which a starship dumps its Matter/AntimatterReactionAssembly (M/ARA), also known as the Warp Core. Performed only in extreme emergencies, when a core breach is imminent, as the procedure will leave the ship without adequate power for defending itself. The antimatter storage tanks are dumped at the same time, since without the core the ship will not be able to maintain a magnetic field which is required to separate the antimatter from the walls of the tanks.

[common Iron Age jargon, preserved by
Unix] 1. [techspeak] A copy of the contents of core, produced
when a process is aborted by certain kinds of internal error.
2. By extension, used for humans passing out, vomiting, or
registering extreme shock. "He dumped core. All over the floor.
What a mess." "He heard about X and dumped core."
3. Occasionally used for a human rambling on pointlessly at great
length; esp. in apology: "Sorry, I dumped core on you". 4. A
recapitulation of knowledge (compare bits, sense 1). Hence,
spewing all one knows about a topic (syn. brain dump), esp.
in a lecture or answer to an exam question. "Short, concise
answers are better than core dumps" (from the instructions to an
exam at Columbia). See core.

On many Unix systems, when a program crashes (usually due to a Segmentation Fault or some other form of memory access error), the default behaviour is to dump the entire contents of the memory the process was using to a file on disk. This is usually named something along the lines of "program_name.core" or just simply "core".

To most people this is quite useless. With the typical sizes of many program nowadays, these dumps can be very large and take up an annoyingly large amount of space (especially if you have a home filestore with a quota and something like netscape coredumps). On Linux systems you can set the maximum size of core files with the ulimit command, eg.

$ ulimit -c 0

Will disable coredumps (setting the maximum size to 0). To enable them, set the limit to some fairly large value, eg.

$ ulimit -c 1000

Core files are actually useful to programmers. The contents of memory including the stack are included in the core, enabling the programmer to find exactly where the program crashed. You can load the core file using a debugger such as gdb:

You can of course disassemble the functions and find exactly where the crash occurs, but I wont go into a full explanation of how to use gdb as that belongs elsewhere. Personally I find that knowing what function it occurred in is usually enough information to locate the bug.