bug#22790: 24.5; Infinite loop involving malloc called from signal handler

[Daniel Colascione]

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. It's not just the printf calls that are
unsafe --- it's everything that happens there.  But there is little
interest in making Emacs robust in this way.

signature.asc
Description: OpenPGP digital signature