From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs Date: Thu, 8 Apr 2021 18:14:21 +0200 Message-ID: References: <87im5ofp3z.fsf@md5i.com> <870479cc-efd3-3a19-98a3-1d7a8b9346e8@gmx.at> <79cfe67d-3a2c-952d-7c51-20e8a4859380@gmx.at> <87czv6q1f8.fsf@md5i.com> <233daa4b-ca64-955f-2612-49a0503b1938@gmx.at> <8735w2p8oc.fsf@md5i.com> <5181da75-e80d-22e0-bdcb-a0ffdc1bac6a@gmx.at> <5c4e5857-6a76-b8e8-204b-b4a855e95a16@gmx.at> <8f4516d5-1080-71bb-7da7-acf7832d5529@gmx.at> <87r1jlvnrc.fsf@md5i.com> <871rbkn6op.fsf@md5i.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11315"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Welsh Duggan , "schwab@linux-m68k.org" , "47244@debbugs.gnu.org" <47244@debbugs.gnu.org> To: Michael Welsh Duggan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 08 18:37:49 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUXf9-0002nh-Vh for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Apr 2021 18:37:47 +0200 Original-Received: from localhost ([::1]:38456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUXf9-0005jS-0C for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Apr 2021 12:37:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUXX2-0006dN-Kc for bug-gnu-emacs@gnu.org; Thu, 08 Apr 2021 12:29:24 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36506) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lUXJ8-0007CU-0c for bug-gnu-emacs@gnu.org; Thu, 08 Apr 2021 12:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lUXJ7-00019V-Qn for bug-gnu-emacs@gnu.org; Thu, 08 Apr 2021 12:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Apr 2021 16:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47244 X-GNU-PR-Package: emacs Original-Received: via spool by 47244-submit@debbugs.gnu.org id=B47244.16178984814389 (code B ref 47244); Thu, 08 Apr 2021 16:15:01 +0000 Original-Received: (at 47244) by debbugs.gnu.org; 8 Apr 2021 16:14:41 +0000 Original-Received: from localhost ([127.0.0.1]:48052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lUXIm-00018i-SZ for submit@debbugs.gnu.org; Thu, 08 Apr 2021 12:14:41 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:43359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lUXIi-00018R-1N for 47244@debbugs.gnu.org; Thu, 08 Apr 2021 12:14:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617898463; bh=y3++rXeKV0eQ/sXzMoNBWXb9tUwzNnlvm+QGrVPxBFA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Dp0qno/z6lenA0XDDZyzclZ1hS/BFE7C54t8epHdkbmSn3BgfD/vmbLBYQIsYvRMO ZIbk8n7LY1mDFAEHjNDQBpV0nutChXHPRy51Sm+oPgitW9rm37FE3aPCSBIy5QnfJk z5Wa3yhpmGme8TZ8awcmGYzs4s1Y6lNWlqh9GBdc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.147]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3UZG-1lTz491swc-000dVS; Thu, 08 Apr 2021 18:14:23 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:og7JKNO8UcnFUCvN9iVUzan1dCTMT8Vw6X9s3NdnNEaW0FTU0YI b9E15nfVhX0qsGg9pMPngtB13MoE7kh1/e7e+E0tMf3uiDblLLy+T9tjCM6sFT5pgsUNoiw u+gh9HbPSYvo8LOfH9bzsYTLKbhhzRaIH/P06w5FC+/cDAHWPuqTdu2rdfSsoGtCmreptZh 7lw4NverHIP2cprRTjmuA== X-UI-Out-Filterresults: notjunk:1;V03:K0:6riimCHGmrE=:LXLjE7Le4EGbM24yQXErmk uRQJjXMH+qd7JnSTCrjCX8gF8dLELYF5yPbGEPBhvL8MaMiGvllf4NKB0GweOUdy6Rvpx+7V9 YewKhVv1EutpMlMp45io+jfjvfNq9pxVfLk6FeJg6cK1JbKCu5dDl1pqLE3uIroifrDj76FY8 4/CFp4O9SW6ub8HcBhnqh8RfJlvEaHHwESeJfgwnSeZAUxk2dWeDcv6n5szSCyIxNNXIC+zA2 2SqNPkFQy0cdQ34SqVnl0rXgAcxAxPC47aexgVnRaHG4Gzt+Vgkk1rgxkkTpSmRc5L4KUnWK+ e8ZrsA4QXlpuzwi4+tRgL+MJQLgMiQ7/O6w3H5rlARGtSms7+hZe1b/SG0rA9myIPU/PpkFQm 8wipHp4i0F2N2MkoRCIIbUtJu8FqxjXLDVZ7RuzafwWH2zsdkepAj2MS154Eiwnpn5I8IxW/J StSNhQsAWkOkTZ8fEgA72eG3iAfxLlVoxSMu+FhXT/CRSfUczRUtJdX9IL7n0ca+nNcpsrBdz UXoA9q5DzGzRNFkWH81m//lswelLSSO4cYqwWAo8iC19NqoqGta816E0QvpUorDsL7MrumjAS XIzvaSH2tKrkvOS46wTbtl8ktry6zG3KhlFuW7KIoSa8/D6f1rO8YWfr2JXQ/eFzAni+bK4Al HSe20vo8rVT0Qk545HmJnpw724g7w4VBt24FuIOo3TBRs1zcvKs7STz+3d3ltlCAdISpOdElh g+y9poqyLeJQLaNNXh69KpP+TSdiYBdx56LOaO81z8UQbvBj2OqGz6fboXhPpljVgqyhzJsV X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203740 Archived-At: > Before that, I include the backtrace with your latest patch. And here's > the interesting bit: > > (gdb) p Vwindow_list > $2 = XIL(0x55555863cae3) [...] > (gdb) p Vwindow_list_2 > $7 = XIL(0) The last one should be the clue, indeed. If it were the expected six windows list we couldn't say much, but nil means it got reset somewhere and never resurrected by window_list. > Right before this I hit a breakpoint that that I had set up that, once > again, implied that in this call of window_list() happened subsequent to > a call to window_list() that didn't complete, somehow. > > Before running with block_input(), unblock_input(), I'm going to modify > the sources to set a physical variable to one on entrance to the if > block and set it back to zero at the exit. At least then I can be sure > that an unintended termination of this function is really happening and > that it is not a debugger artifact. Good. Otherwise we're back at zero. martin