When a Unix process accesses an invalid memory location, or (more rarely)
executes an illegal instruction, or (even more rarely) something else goes
wrong, the Unix operating system takes control. The process is incapable of
further execution and must be killed. Before killing the process, however, the
operating system does something for you: it opens a file named ``core''
and writes the entire data space of the process into it.
Thus, ``dumping core'' is not a cause of problems, or even an effect of problems. It's something the operating system does to help you find fatal problems which have rendered your process unable to continue.
One reads a ``core'' file with a debugger. The two most popular debuggers on
Unix are adb and gdb, although occasionally one finds dbx.
Typically
one starts a debugger like this: ``adb bin/circle'' or
``gdb bin/circle lib/core''.
The first thing, and often the only thing, you need to do inside the debugger
is take a stack trace. In adb, the command for this is
``$c''.
In gdb, the command is ``backtrace''. In dbx, the command is
``where''. The stack trace
will tell you what function your program was in when it crashed, and what
functions were calling it. The debugger will also list the arguments to these
functions. Interpreting these arguments, and using more advanced debugger
features, requires a fair amount of knowledge about assembly language
programming.
If you have access to a program named ``Purify'' ... learn how to use it.