
To dump core or not to dump core
Excerpts from ext.python: 28-Nov-94 To dump core or not to dump.. Jim
Quote:
> When fatal errors occur in (Unix) python, it dumps core. This is OK
> when debugging, but is a drag in general.
> I propose that, by default, the Unix version of Python should not dump
> core on fatal errors. (An appropriate call to setrlimit() can be used
> to prevent core dumps.) A command-line flag could be provided to
> allow core dumps on demand, or a module interface to setrlimit (and
> getrlimit) could be provided.
We went through this recently with ILU. When ILU detects a kernel bug,
it used to SEGFAULT, because it assumed that either you were running
under gdb, or if not, would like a core dump. It still does this. We
prevent core dumps, if necessary, by setting the coredumpsize shell
variable.
On the other hand, we have changed the way ILU behaves for memory
allocation failures, and are considering making this the default fatal
error case. We reasoned that a running program is more useful than a
dead program, for debugging purposes. So the default behavior, if
malloc() fails, is now to go into an endless loop. This provides the
user with a number of alternatives: they can kill the process, or they
can attach to it with a de{*filter*} and inspect it. Since the process is
still live, ephemeral state such as open file descriptors is preserved.
Better than a coredump.
The endless loop is actually
while (1)
sleep(10);
so few actual CPU cycles are consumed.
It seems to me this would be a reasonable thing to do for Python, as well.
Bill