Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

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

On 12/22/2015 01:08 PM, Eli Zaretskii wrote:
>> Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com,
>>  p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Tue, 22 Dec 2015 12:52:05 -0800
>>
>>> If you only longjmp a short while, you have no idea how much stack you
>>> freed.  You might as well be just 200 bytes below the level where the
>>> stack overflow hit.
>>
>> Which is why you setjmp in places where you have a significant stack
>> reserve.
>
> There's no way of doing that portably, or even non-portably on many
> platforms.  You simply don't _know_ how much stack is left.

You can probe at program start and pre-allocate as much as is reasonable.

>>> No, the core isn't in a bad state.  Longjmp is not an abnormal path,
>>> its semantics is very simple and clear.
>>
>> Longjmp, by itself, is simple and clear. What's unreliable is longjmping
>> to Lisp at completely arbitrary points in the program, even ones marked
>> "GC can't happen here" and the like.
>
> We longjmp to a particular place, not arbitrary place.

But we longjmp _from_ anywhere, and "anywhere" might be in the middle of
any delicate code sequence, since the compiler can generate code to
write to new stack slots at any point.

>> You say Emacs shouldn't crash.  Fine. We can't make that guarantee
>> if the crash recovery code breaks program invariants.
>
> Crash recovery doesn't need to keep invariants.  Or maybe I
> misunderstand what invariants do you have in mind.

Any stack allocation anywhere in the program can longjmp. It's
impossible to reason about safety in that situation.

>
>> If you want to longjmp, you need to do it at certain well-defined
>> points only. The current approach is a bug machine.
>
> No, it isn't.  There's a small number of places (2?) to which we
> jump.  That's all.
>
>>>> We can gracefully recover from stack overflow of Lisp code. We
>>>> cannot recover from stack oveflow at arbitrary points in the C core.
>>>
>>> We can and we do.  The recovery has only to be good enough to allow
>>> saving your work and exiting.  That's the only goal of that
>>> protection: allow the user to exit normally, after saving their work.
>>
>> I'd rather rely on autosaves.
>
> It's not reliable enough, because it happens relatively rarely.  Doing
> it much more frequently will be an annoyance with many buffers.  And
> then there are buffers that don't autosave, but the user might still
> want to do something with them if she needs to abandon ship.
>
>> Failing that, we should allocate guard pages, unprotect the guard
>> pages on overflow
>
> Thats what the OS is for.  It would be wrong for us to start messing
> with page protection etc.  The exception caused by stack overflow
> removes protection from the guard page to let you do something simple,
> like run the exception handler -- are you suggesting we catch the
> exception and mess with protection bits as well, i.e. replace one of
> the core functions of a modern OS?  All that because what we have now
> is not elegant enough for us?  Doesn't sound right to me.

We have a program that has its own Lisp runtime, has its own memory
allocation system, uses its own virtual filesystem access layer, and
that brings itself back from the dead. We're well past replicating OS
functionality.

It's not a matter of elegance: it's a matter of correctness. The current
scheme is unsafe.

>
>> and call out_of_memory so that it's obvious Emacs is in a bad
>> state. This way, we don't have to longjmp out of arbitrary code
>> sequences.
>
> There's no problem longjmping out of arbitrary code sequences.  When
> you debug a program, you do that all the time.

In GDB, interrupting normal control flow is not part of standard
debugging practice. Lisp-level debugging can return to toplevel from
anywhere, but only between lisp form evaluations, and returning to
toplevel still runs unwind-protect handlers. The longjmp on stack
overflow does not.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]