Re: Crash recovery strategies

[John Wiegley]

>>>>> Daniel Colascione <address@hidden> writes:

> But that the emacs -Q process won't be doing any sending. The next regular
> Emacs process will do that. The process we spawn from the sigsegv handler is
> just for asking the user what to do about the crash. If we can't launch the
> process, we can do the default thing, the right choice for which is probably
> to write the crash file.

Hmm... something about this approach just doesn't feel right, but I'm not sure
what it is that I don't like. I'll have to sleep on it.

>> I'm OK if sometimes it just doesn't work. The new async Emacs idea sounds 
>> like
>> it has a host of unforeseen complications waiting behind it.

> The problem is that we can't *tell* whether it doesn't work. If we try to do
> that, we can just silently not execute.

This isn't going to be a 100% solution to any problem, so I'm OK if this is a
scatter-gun approach.

>>> On next startup, for each crash file we find that isn't owned by a running
>>> Emacs, we'll
>> 
>>> 1) read and parse the crash file,
>>> 2) prompt the user to send a bug report, and
>>> 3) restore the contents of persisted buffers.
>> 
>>> To avoid crash loops arising from certain arrangements of buffer contents,
>>> we can restore each buffer in fundamental-mode, and with a name indicating
>>> that it's recovered data.

> If implementing a scheme like this is what it takes to kill the stack
> overflow code, I think I can implement it.

Wouldn't the stack overflow code still exist, to catch the error? Maybe I
haven't understood something... Can you explain how this approach removes that
code?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2