Re: History file clobbered by multiple simultaneous exits

[Chet Ramey]

On 7/24/13 2:53 AM, Geoff Kuenning wrote:

> I have to confess that I'm equally confused.  The probability of a
> malloc failure seems vanishingly small; my bashes are only about 20M
> virtual, my history size is a measly 500, and my current history is just
> over 8K..
> 
> I can't think of an interleaving in either 4.2 or 4.3 that would result
> in this behavior.  No matter what the interleaving, one of the instances
> ought to finish last.
> 
> I wrote two test programs to try to reproduce the behavior, and neither
> failed.  This makes me wonder if it has to do with how bash deals with
> signals (I'm assuming a SIGHUP is involved, though it might be another).
> Perhaps bash is getting a second signal during the brief period when the
> buffer is being malloc'ed and the history file is being formatted, and
> that second signal is killing it before it can do the write?  That seems
> unlikely, but sometimes computers surprise us.

If you are using whatver `close' button your window manager provides to
exit the shell rather than exit or ^D, it's possible that there is a signal
race condition involved here.  Many window managers send SIGHUP/SIGKILL to
running processes on window close.

Bash-4.2 runs its handlers for terminating signals like SIGHUP immediately,
interrupting whatever is in progress.  That, coupled with attempting to
save the history from interactive shells killed this way, could result in
zero-length files if the signals arrive at the right time.

I did a lot of work for bash-4.3 to avoid running too much code from signal
handlers (even longjmp is not safe).  I think that, along with the code to
write the history file I outlined previously, should reduce the size of the
window considerably.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/