On 12/23/2015 10:09 AM, 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 >> Date: Wed, 23 Dec 2015 09:56:31 -0800 >> >>>> We can make the alternate signal stack as large as we want. >>> >>> Not as large as is safe to run arbitrary Lisp. >> >> Then don't run arbitrary lisp after we've segfaulted. > > It's out of your control. > No it isn't. We don't have to run the generic auto-save logic: in fact, we probably shouldn't run arbitrary lisp, because a fatal signal indicates that the process is in a bad state. Instead, if we really want to minimize the possibility of data loss, we should use a pure-C autosave system directly from the crash handler, not longjmp from arbitrary parts of the program to toplevel. The other option is to use a guard page: on stack overflow, unprotect the guard page (allowing program execution to proceed normally for a little while longer --- again, no longjmp), Fsignal at the next opportunity to QUIT, invoke out_of_memory after the signal, and let users save at that point. You're against installing a guard page because it's something the OS does. I don't see how that's relevant, since the OS gives us APIs achieve exactly the behavior we want. The other objection to using a guard page is that it requires determining in advance the maximum amount of stack space we want to give Emacs, but if we limit it to 8MB on Windows, 8MB of stack space should be enough anywhere. Regardless, the current mechanism does not achieve its goal. It's utterly unsafe even without module code added to the mix. A mechanism that invokes arbitrary undefined behavior is *worse* than useless.