Daniel Colascione schrieb am So., 13. März 2016 um 10:22 Uhr: > On 03/04/2016 06:23 AM, Andreas Gustafsson wrote: > > Eli Zaretskii wrote: > >> Is this a GUI session or a text-mode terminal (a.k.a. "TTY") session? > > > > This is a TTY session. > > > >> In any case, this code is run as part of the so-called "emergency > >> escape", when you type C-g more than once while Emacs is busy doing > >> something that cannot be interrupted. In that situation, we are way > >> past the point where invoking undefined behavior is of any concern, > >> because the only thing we can do then is auto-save and commit > >> suicide. > > > > Not necessarily - there is also the option of continuing what emacs > > was doing, which is what I would have done, by answering both the > > "Auto-save?" and "Abort (and dump core)?" prompts with "no", if those > > prompts had actually appeared. But they didn't, because emacs entered > > an infinite loop trying to print them. > > > >> You need to use "finish", not "step" or "stepi". > > > > I will try that the next time the lockup happens, but I'm quite sure > > it won't do anything useful. > > > >> I don't think the loop can reasonably be inside libpthread, > > > > Why not? We are talking undefined behavior here, after all. If you > > find looping in libpthread surprising, just wait until the nasal > > demons appear :) It could be something as simple as trying to acquire > > a spinlock that was already held when the signal occurred. > > The Emacs maintainership has decided that undefined behavior in signal > handlers is perfectly okay. I've patched this dangerous code out of my > Emacs, and I suggest you do too. Could you maybe share the patch here? Thanks.