Re: Crash recovery strategies

[Daniel Colascione]

On 01/03/2016 02:59 PM, John Wiegley wrote:
>>>>>> 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.

Fair enough. I don't think in core we've had any features that rely on
Emacs re-executing itself. I've wanted to make the byte compiler do the
same for years though, so it might be worth seeing how hard it would be
to make this work.

>>> 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.

The problem is that displaying a GUI dialog box requires re-entering the
main event loop, which I think risks too much undefined behavior. A
separate process sidesteps the problem.

>>>> 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?

The code that bothers me is the code that longjmps *out* of the sigsegv
handler that catches stack overflow. The handler being there is fine.
Under my proposed scheme, we won't longjmp out of the handler unless the
user tells us to do that.

signature.asc
Description: OpenPGP digital signature