From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#22790: 24.5; Infinite loop involving malloc called from signal handler Date: Sun, 13 Mar 2016 20:41:52 +0000 Message-ID: References: <83povmgfnn.fsf@gnu.org> <22228.22862.708667.152490@guava.gson.org> <838u1yzij7.fsf@gnu.org> <22233.39509.879175.437974@guava.gson.org> <56E5312B.2050008@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114080c045988d052df43230 X-Trace: ger.gmane.org 1457901801 26919 80.91.229.3 (13 Mar 2016 20:43:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2016 20:43:21 +0000 (UTC) Cc: 22790@debbugs.gnu.org To: Daniel Colascione , Andreas Gustafsson , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 13 21:43:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afCr1-0002Jl-9i for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Mar 2016 21:43:11 +0100 Original-Received: from localhost ([::1]:37632 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afCr0-0000iX-Nk for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Mar 2016 16:43:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afCqv-0000f7-Mo for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2016 16:43:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afCqs-0002TI-DZ for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2016 16:43:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afCqs-0002TE-AE for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2016 16:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1afCqs-0005MI-0I for bug-gnu-emacs@gnu.org; Sun, 13 Mar 2016 16:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Mar 2016 20:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22790 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 22790-submit@debbugs.gnu.org id=B22790.145790173020535 (code B ref 22790); Sun, 13 Mar 2016 20:43:01 +0000 Original-Received: (at 22790) by debbugs.gnu.org; 13 Mar 2016 20:42:10 +0000 Original-Received: from localhost ([127.0.0.1]:47203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1afCq1-0005L9-Lh for submit@debbugs.gnu.org; Sun, 13 Mar 2016 16:42:09 -0400 Original-Received: from mail-lb0-f172.google.com ([209.85.217.172]:35169) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1afCq0-0005Kw-As for 22790@debbugs.gnu.org; Sun, 13 Mar 2016 16:42:08 -0400 Original-Received: by mail-lb0-f172.google.com with SMTP id bc4so215082093lbc.2 for <22790@debbugs.gnu.org>; Sun, 13 Mar 2016 13:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R+jE/bsFGwV0Gx76mNH//59JdnJL7CudlTyBXHODbJ4=; b=Bqcedx7UmjDG8W0czOTrj2g83RbGaIfZDhBUmDaxPRXZdCCw0QbCsi3W2zQMK8p0Sz 8jL5JORoermre4+0buYPtDVEqqTnWeMEhhYhPaonJ61zd4k+8g834mjsGH9KGn7dXb51 0ftvX0X+/zf3Ug3DBSjTfUBLtJt4bJXBO47L7X0n0s0WiDfKHJaM9aF7EzLX+HaZlpoH FpLWUEoWe0VB+hCoMdJVBSzjgEwd39Vw5xPzvPumOKlrmUra3TSNZ1dH7FrEDK9JNBQU Ez8ck3auECoeereGpxPuIrPu4YUP7it2OX0z9WTfsma9Zuw16tF/57s3fs+I+nU2Gulu D0fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R+jE/bsFGwV0Gx76mNH//59JdnJL7CudlTyBXHODbJ4=; b=CBaCuHqhe9ZvhOyjs7kdZKnvBkL0qcXJ1D3OU/Hko5/MqWI6rYlKJzwkfQEN5zIFja gdrOZoAzjtOQFsTJY+DzLqqql11OcXNkwGoL4EdSfV4nrK8DTako7OHXBfFGq41A0SWn dkpYvqbMCSf6BoHNKa6xXGUG29Rn+7qhbCI1X55QkxWFh0SWhoVmaUTizl+5GzLFUQOx +Y95run60cZlB8nBbTVlEAslZfUb30T6xUjPYXIZFmqUcuhb06y294mjkJLEUhvFB94Z x45Lut/ZePClJc4EWuKfTMPzK/KOnyTxkFpqw4er334IGbJRHz0/qACM47KQb0C8Rjht nHiw== X-Gm-Message-State: AD7BkJKHW+OBTrr6m7hou3l2caLiBFAxhDB8DKzyl5UwUuf6nGF85Rr8y6svoMLmvsZh8bJTpxcURfxkDM5Stg== X-Received: by 10.25.81.144 with SMTP id f138mr6722232lfb.146.1457901722242; Sun, 13 Mar 2016 13:42:02 -0700 (PDT) In-Reply-To: <56E5312B.2050008@dancol.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114868 Archived-At: --001a114080c045988d052df43230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Colascione schrieb am So., 13. M=C3=A4rz 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. --001a114080c045988d052df43230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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
--001a114080c045988d052df43230--