Re: Crash recovery strategies

[Daniel Colascione]

On 01/03/2016 02:43 PM, John Wiegley wrote:
>>>>>> Daniel Colascione <address@hidden> writes:
> 
>> Are you worried about startup time or correctness? Either way, wouldn't
>> wouldn't spawning a new emacs with -Q solve the problem?
> 
> Except that it wouldn't be configured to use the right mail sender. :(

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.

>> That's a reasonable UI, but popping up a window or otherwise displaying UI
>> in-process might not work. Instead, we can fork and exec a new Emacs to
>> interact with the user, and read from a pipe that process inherits a byte
>> telling the crashing Emacs what it should do. All that's perfectly legal to
>> do from an async-signal-unsafe context.
> 
> 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.

>> If we had real data, I'd be more comfortable with the feature. As it is, we
>> have to rely on user reports, and I suspect that most users won't bother
>> reporting occasional hangs and crashes if it's any harder than pushing a
>> button. Given the absence of quantitative information, I'd rather avoid
>> undefined behavior.
> 
> OK, your objection is duly noted.
> 
>> That works. In particular, on startup, we can create a new, empty file under
>> ~/.emacs.d and keep a file descriptor to it open. Normally, we'll never
>> write to the file. If we see a crash of *any* sort, however --- stack
>> overflow or some other bug --- we'll prompt the user. If the user elects to
>> continue using Emacs or attach a debugger, fine.
> 
> Ah, showing the report on the *next* Emacs invocation is also something that
> OS X applications do (as an example of prior art). I like that idea.
> 
>> 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.
> 
> I like this idea. It's like Windows booting into safe mode, except it's safe
> buffers.
> 
>> Of course, the downside is that the code to do this doesn't exist yet.
> 
> I'd like to know what others think (maybe they are ignoring this thread now,
> so I've changed the subject). But I feel like there is some convergence now.

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

signature.asc
Description: OpenPGP digital signature