[Top][All Lists]

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

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Sun, 3 Jan 2016 08:31:35 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Daniel Colascione wrote:
In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to
detect C stack oerflow and longjmp back to toplevel. It's important to
note that we don't just longjmp when we're in a safe position: we
longjmp from *anywhere*, even if we're, say, in the middle of malloc.

Although that particular code path may have been introduced recently, for decades Emacs has longjmped from arbitrary locations due to other signals, so adding a longjmp for SIGSEGV does not introduce new issues.

The code is fundamentally flawed and cannot be made to work
properly on any platform.

The code is part of Emacs 24.5 and does not appear to be causing problems; at least, I don't recall any bug reports from the field. The other longjmps, which are fundamentally flawed in the same way, have been in Emacs for decades, and also seem to work well enough in practice.

No other program attempts to recover from
stack overflow this way.

True, not *exactly* in this way, but Emacs is pretty special.

In practice, the Lisp stack depth limits provide enough protection

That won't be true once once people link in dynamic modules, since the modules may not use Lisp and may exhaust the C stack. And even without modules, I recall people running into stack-overflow issues in the regular-expression code. Did that ever get fixed? Even if so, most likely other such issues are still lurking in the regexp code.

The existing auto-save logic
is good enough for data recovery, especially if we run the sigsegv
handler on the alternate signal stack (which we can make as large as we
want) when possible.

Something like that could help, yes. But the existing auto-save logic can longjmp out, so I don't see how this would address your concern about longjmp.

One possible way forward here is the approach recommended by GNU libsigsegv. See <https://www.gnu.org/software/libsigsegv/> "About stack overflow handlers". In the past we've avoided libsigsegv's approach because it was considered to be too heavyweight, but it would be safer to do something along the lines that it suggests, or perhaps even to use libsigsegv if available.

If we keep this code in Emacs, it sets a precedent for other terrible
forms of crash recovery, like silently ignoring writes to NULL ...

Naah. We're pragmatic, not stupid.

reply via email to

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