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: Mon, 29 Mar 2021 18:05:35 +0200 Message-ID: <2d0dbdc8-3678-cd21-234a-9c63bb004629@gmx.at> References: <87im5ofp3z.fsf@md5i.com> <83h7l8fdfa.fsf@gnu.org> <871rccgqyz.fsf@igel.home> <83eegcfbrh.fsf@gnu.org> <8735wrrjx7.fsf@md5i.com> <83a6qzfxmc.fsf@gnu.org> <87sg4rclim.fsf@md5i.com> <83k0q3dzj7.fsf@gnu.org> <83czvvdw7o.fsf@gnu.org> <14e14f28-7ece-cd98-5e49-d4583a0153a0@gmx.at> <16b279ef-a1c2-cd41-b18c-69383174c72a@gmx.at> <87a6qs7z60.fsf@md5i.com> <83eeg3kawg.fsf@gnu.org> <83y2e6kp9t.fsf@gnu.org> <83tuouknpb.fsf@gnu.org> <83sg4eknh5.fsf@gnu.org> <83r1jykmt0.fsf@gnu.org> 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="22098"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mwd@md5i.com, schwab@linux-m68k.org, 47244@debbugs.gnu.org, mwd@cert.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 29 18:08:56 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 1lQuRj-0005gI-Ev for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Mar 2021 18:08:55 +0200 Original-Received: from localhost ([::1]:54780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lQuRi-0004bY-Ca for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Mar 2021 12:08:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lQuOx-0002mv-1s for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 12:06:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37849) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lQuOw-0001bm-OL for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 12:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lQuOw-0002vn-GL for bug-gnu-emacs@gnu.org; Mon, 29 Mar 2021 12:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Mar 2021 16:06:02 +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.161703395211247 (code B ref 47244); Mon, 29 Mar 2021 16:06:02 +0000 Original-Received: (at 47244) by debbugs.gnu.org; 29 Mar 2021 16:05:52 +0000 Original-Received: from localhost ([127.0.0.1]:49395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuOm-0002vL-8l for submit@debbugs.gnu.org; Mon, 29 Mar 2021 12:05:52 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:53811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lQuOj-0002v3-SK for 47244@debbugs.gnu.org; Mon, 29 Mar 2021 12:05:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617033937; bh=bfcNuxOIdvTGis/2fMabX3b23HF0I55RVsga+7hI6bc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=X6ii2YtjTI7AfacLocmT2ZD/Vj/KWwHow7JSeXDFGFr7kjyvisCzgxoxjHisFJTkq 8TSwDugmaaKTg980pL/SlpvhihPeM6V0qqqJP8Kw1xv09ZbPxbCVPv21m0a2NTw016 zXnWmubfqeKJn0+Z3EG1WrZ3FyIzAalOy6OdYiGk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.25]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4QwW-1lb7Qd1HmA-011TqQ; Mon, 29 Mar 2021 18:05:37 +0200 In-Reply-To: <83r1jykmt0.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:zMWwYw8vnCIMMgFDkCXMKyQAgtnh8UTGmySR9O8okljlewkl3aB doc/xi7G1tnh4w+JJapPpR1CrJnMabgn+Ql0WoHSR9VMrLx7tXi94Pvqu2hm/CUy7wJZSy0 1PSXdl8mIf4RbGhxI3juzuqoKwGKKiq7Yyig3DTTJOd2aP+AQL6WIaWgAm1lbu72Agm0AtI /rg7iG7amWdVNLh4F5s5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:K+48YhWYcFo=:Oyex3stDa3p6xKFZvmC0hz 1clBq9MKxv//FOCutLuHS3eBvFtiDW56YvyUAbKbql3yXRUzyytEv1bpm9NZWlaKpobZZ+d2K uIAaFuEXBt3+ud1HdkaFPWiAyfycQY9Ahgyuf0op+G7p2PYiFkWUB77HdshmQ/K4blyNftJoO Xn3Yvgam++y/uielL7HndkhBuJ6mkHGWMMndjEhJL30bDzwvCTEKCbD1HjfXdCFnXqS8Kmgvx lVq2YSlyhkMCPyjym9g1uOEqasCYmx3vNSZOPTtg4dMUL62f/6qsQO6ZN6Jj8E7/17zpgm6zC f98nyqg2x8q7PGg4qC7eUqsYbbK079iiOeNgau5GIkEsEi6jdQhVgkz9VBoS6dTIuldpvFJ4P CeHYB/AaeK6kZWY7WClct47spqnasd9fbwMDETln279wo2MyOTxtlbctCFeNMwTYmLm7Hbcee D3Y1IqrzG3vlJlt+8FQa+RirX7NtT507gT5H7WK4YIKjcgowJ62VbCgBMIo9FoxAnG8wFBfUz hO8dq/Mwjj+pkMFx9MeuCidaC5xu7ZogA6T79zZ6xu/Y8Lj8pj8BtakDaPkCmakXQ84uYwwUg ij+3SXNYjcfLETelRln6F3IuKEX/R15cItixana4+J7+m8jykKLLeOstQhfuUwOQ0MSVdiePl ElJG4O8OXaXEykQ9u1GttsJLeRShsorRGgEwTblYVlhoM1ZzlazWPONueftfKirbb4XFQREXc Y+/ZeOOPIpL+MmtcedFWANb9XN3jhj/H6JQ1jTgvkapuYO4goKS03JnKpcD74kl/UvKTCz54 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:203253 Archived-At: > Martin, could it be that replace-buffer-in-windows fails to replace a > buffer? Suppose kill-buffer is called to kill a buffer that is shown > in the selected window, but replace-buffer-in-windows fails to replace > it -- can that happen? That's what we tried earlier with the check in `switch-to-prev-buffer'. Michael did you run with that check this time or did you remove it? If the latter, please reinsert it for the next time. But let's recall that at the time of the last segfault that particular check did not trigger. > And another question: can a window be selected if its buffer is dead? > Or is it possible to set a dead buffer as a window's buffer? From what we can say now one of these must have happened. The dead buffer comes from the selected window. It does not come from the attempt to restore the current buffer from a temporarily saved one. One thing I'm not even sure about is whether the selected window is still "live" when were trying to make its buffer current. Michael is this "window" supposed to be the only one on its frame? Are we sure that it is not the minibuffer window? In either case we could try to investigate its parent and geometry: What do p XWINDOW (selected_window)->parent p XWINDOW (selected_window)->prev p XWINDOW (selected_window)->next p XWINDOW (selected_window)->top_line p XWINDOW (selected_window)->pixel_height print? Thanks, martin