GNU bug report logs - #22790
24.5; Infinite loop involving malloc called from signal handler

Previous Next

Package: emacs;

Reported by: Andreas Gustafsson <gson <at> gson.org>

Date: Wed, 24 Feb 2016 13:09:01 UTC

Severity: normal

Tags: moreinfo, wontfix

Found in version 24.5

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 22790 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>, Andreas Gustafsson <gson <at> gson.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 22790 <at> debbugs.gnu.org
Subject: Re: bug#22790: 24.5; Infinite loop involving malloc called from
 signal handler
Date: Sun, 13 Mar 2016 20:41:52 +0000
[Message part 1 (text/plain, inline)]
Daniel Colascione <dancol <at> 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.
[Message part 2 (text/html, inline)]

This bug report was last modified 8 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.