[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: Tue, 22 Dec 2015 08:39:53 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Eli Zaretskii wrote:
     The only real change we have to make is to have Emacs longjmp not to
>     return_to_command_loop (which might skip module frames), but to longjmp
>     instead to the most deeply nested entry point from module code into
>     Emacs, which we can set up in advance whenever a module calls into the
>     Emacs API.
>Yes, that looks like something we should do, then, to get stack overflow 
checking working with modules.
If that means letting modules run arbitrary stack unwinding code on
the alternate stack, I'm against that.

Likewise. My thought was more to require that the module code's most deeply nested frame must be on the main stack, with some (perhaps configurable) amount of unused stack space above it, so that any module-specific unwinding would be done on the main stack. In other words, the module code knows about stack overflow and has methods (either a runtime check on each call as Daniel suggests, or guard pages and constraints about module stack frame sizes if this works and has better performance) to detect it.

We might also want to put in something to catch trivial stack-overflow infinite loops, if they turn into an issue. This would give up on catching a looping stack-overflow and would go back to the previous catch. This would break destructor-based invariants, but that's often better than crashing. It's akin to the existing 3x C-g signal, which breaks invariants all over the place (including invariants in module code!) but in my experience is crucial.

reply via email to

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