Crash recovery strategies (was: Dynamic modules: MODULE_HANDLE_SIGNALS etc.)

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

>>>>> Daniel Colascione <dancol@dancol.org> 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. :(

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

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]