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

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

Daniel Colascione <dancol@dancol.org> 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.

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]