Eli Zaretskii schrieb am Di., 22. Dez. 2015 um 17:11 Uhr: > > Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, > tzz@lifelogs.com, > > emacs-devel@gnu.org > > From: Daniel Colascione > > Date: Mon, 21 Dec 2015 22:14:38 -0800 > > > > And even if it were OK for (say) 'cat' to dump core due to > > > stack overflow in a typical environment (which it's not), Emacs is more > > > important than 'cat', because people use it as an interactive text > > > editor and do not want to lose their work. > > > > > >> we already crash if we overflow the stack while we're GCing. > > > > > > If so, that's a bug that should get fixed. It's not an excuse to > > > introduce similar bugs. > > > > > > Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs > > > should not crash. > > > > Ideally, we wouldn't have bugs. But we do, and when we hit them, we > > should crash reliably and deterministically if we can't recover > > reliably. > > I'm sorry, Daniel, but that kind of philosophy is a non-starter with > Emacs. Saving the user's work even in some cases is much better than > not saving it at all. And the current scheme is quite reliable, it > works in many scenarios, though not all of them. > > As for bugs that cause fatal errors, Emacs always tried to catch them > and at least auto-save. > IIUC this code (terminate_due_to_signal) already auto-saves without calling Lisp (or module) code, so this should be usable. We just need to make sure that module code is not run after a stack overflow. Would it be possible to chose this path if a module function is running?