emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.


From: Daniel Colascione
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Mon, 21 Dec 2015 22:14:38 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 12/21/2015 10:09 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
>>> That would certainly be easier to implement! But as a user I would not
>>> >find it acceptable.
>> You find it acceptable in most other programs.
> 
> ?!  No, I don't find it acceptable for any program to dump core on stack
> overflow.

Most programs you use don't bother trying to detect or recover from sack
overflow. Why should they? C stack overflow is a programming error. It's
like hitting an assertion failure. Should we try to recover from
assertion failures too?

> And even if it were OK for (say) 'cat' to dump core due to
> stack overflow in a typical environment (which it's not), Emacs is more
> important than 'cat', because people use it as an interactive text
> editor and do not want to lose their work.
> 
>> we already crash if we overflow the stack while we're GCing.
> 
> If so, that's a bug that should get fixed. It's not an excuse to
> introduce similar bugs.
> 
> Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs
> should not crash.

Ideally, we wouldn't have bugs. But we do, and when we hit them, we
should crash reliably and deterministically if we can't recover
reliably. The current stack overflow scheme can't recover reliably
because it doesn't fix maintain invariants. There are ways to fix it ---
e.g., we can make our own guard pages, mark them PROT_NONE, and on stack
overflow, mark them PROT_READ | PROT_WRITE long enough to reach eval,
*then* signal, but I don't think it's worth it.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]