From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60096: 29.0.60; Crash in format_mode_line_unwind_data Date: Sat, 17 Dec 2022 19:52:12 +0200 Message-ID: <83edsxhq9f.fsf@gnu.org> References: <86a63oen2m.fsf@mail.linkov.net> <83sfhgjqd7.fsf@gnu.org> <86cz8jls87.fsf@mail.linkov.net> <83k02rk1vk.fsf@gnu.org> <83ilibjttu.fsf@gnu.org> <83fsdfjsq9.fsf@gnu.org> <325aaa94-74fa-cf94-b66c-b87c69ebe386@gmx.at> <838rj6ic34.fsf@gnu.org> <83pmciggwn.fsf@gnu.org> <89b63947-5b2d-8bd1-4e9a-7da6cf114ffe@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37511"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60096@debbugs.gnu.org, juri@linkov.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 17 18:53:19 2022 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 1p6bN9-0009bH-47 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Dec 2022 18:53:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6bMv-0001gA-D7; Sat, 17 Dec 2022 12:53:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6bMs-0001fr-Rp for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 12:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6bMs-0006sf-JT for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 12:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p6bMs-0008Fd-9L for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2022 12:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Dec 2022 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60096 X-GNU-PR-Package: emacs Original-Received: via spool by 60096-submit@debbugs.gnu.org id=B60096.167129953631707 (code B ref 60096); Sat, 17 Dec 2022 17:53:02 +0000 Original-Received: (at 60096) by debbugs.gnu.org; 17 Dec 2022 17:52:16 +0000 Original-Received: from localhost ([127.0.0.1]:57152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6bM7-0008FJ-GN for submit@debbugs.gnu.org; Sat, 17 Dec 2022 12:52:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6bM5-0008F9-MG for 60096@debbugs.gnu.org; Sat, 17 Dec 2022 12:52:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6bLz-0006Wt-Oj; Sat, 17 Dec 2022 12:52:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=U04tWcTtslGlWZzQSBuvDFaYNAGqh5qe2svYjncH6Ic=; b=gAFUKD07J26j RuplE6aZEQbvCBFsJDnXpw8rr5kADUksO1H5yHOAqAXTUph1j+QeuZmdxB0V7bGpxpgI0vHdG4l0C KDDqyylPk+KSj0AQol5g/fQZmc6muOvuNhJ0Z1e5r8akgpXzgl2Po41zI6AqHJ+E/N9QMVyYu5k7V QJrvVBEbQNnGYUXpl7AN3rHfgTMv8tj52HgB3x1K8Fwkz5x6oyIb5I97om4j4N5srFk0GGHUrOgSf jDuuFZPoqoGgPRU4rlh99fr/Xu+wwo3+hmO0h6Wq0H6DhMiKCTYtmQ7opCtj6mUvx2/s/cFd5d4RH Br6VWROGjRSlQc08sWomTw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6bLy-0003wR-Uc; Sat, 17 Dec 2022 12:52:07 -0500 In-Reply-To: <89b63947-5b2d-8bd1-4e9a-7da6cf114ffe@gmx.at> (message from martin rudalics on Sat, 17 Dec 2022 18:05:58 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251300 Archived-At: > Date: Sat, 17 Dec 2022 18:05:58 +0100 > Cc: juri@linkov.net, 60096@debbugs.gnu.org > From: martin rudalics > > >> Alternatively, we could exclude windows with a nil buffer in > >> add_window_to_list (think of the case that within the blurb > >> producing code someone wants to consult the window list). > > > > Maybe we should try this on master. I indeed expected > > add_window_to_list to filter such invalid windows and was surprised > > that it didn't. Basically, I don't understand how we never had such > > windows in the list before, since there's no code which actively > > removes them and thus protects the list from holding such windows. I > > think we just have been lucky. > > Probably so far we never tried to call 'kill-buffer' from within > 'set-window-configuration'. If the only "live" window shows *scratch*, > *scratch* gets killed and we kill a temporary buffer before we were able > to recreate *scratch*, window_list will return the empty list. Why the empty list? The buffer gets killed, but windows don't get killed. We still have the frame with at least two windows (including the mini-window). Right? > >> Principally, we should never run 'replace-buffer-in-windows' from within > >> 'set-window-configuration'. > > > > This can no longer be guaranteed, given that other_buffer_safely calls > > into Lisp, and so do a few other primitives. > > What if such a call into Lisp tries to run 'set-window-configuration'? Indeed. Maybe we should protect set-window-configuration from being re-entered? > > You are right in principle, but other_buffer_safely was doing the > > above for many years before we acquired get-scratch-buffer-create and > > started calling it from here. So I think we are relatively safe > > (again, maybe by pure chance). > > Then not calling 'get-scratch-buffer-create' from other_window_safely > would be more safe. You mean, return to what we did before get-scratch-buffer-create was invented? It's possible.