Daniel=
Colascione <
dancol@dancol.org&=
gt; schrieb am So., 13. M=C3=A4rz 2016 um 10:22=C2=A0Uhr:
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&qu=
ot;) session?
>
> This is a TTY session.
>
>> In any case, this code is run as part of the so-called "emerg=
ency
>> escape", when you type C-g more than once while Emacs is busy=
doing
>> something that cannot be interrupted.=C2=A0 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.=C2=A0 But they didn't, because emac=
s 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 su=
re
> it won't do anything useful.
>
>> I don't think the loop can reasonably be inside libpthread,
>
> Why not?=C2=A0 We are talking undefined behavior here, after all.=C2=
=A0 If you
> find looping in libpthread surprising, just wait until the nasal
> demons appear :)=C2=A0 It could be something as simple as trying to ac=
quire
> 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<=
br>
Emacs, and I suggest you do too.
Could you maybe share the patch here? Thanks.=C2=A0