[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.
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
Paul Eggert <=
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., John Wiegley, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03