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.