From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Wed, 12 May 2021 18:54:05 +0000 Message-ID: References: <87tunasd2u.fsf@linaro.org> <83fsyu57oj.fsf@gnu.org> <838s4l5uld.fsf@gnu.org> <83zgx14cal.fsf@gnu.org> <83cztx3v04.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33923"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48337@debbugs.gnu.org, alex.bennee@linaro.org, acm@muc.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 12 20:55:21 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 1lgu0v-0008gH-KX for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 May 2021 20:55:21 +0200 Original-Received: from localhost ([::1]:32996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgu0u-0004co-J4 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 May 2021 14:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgu0c-0004ax-5k for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 14:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgu0b-0006wJ-UM for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 14:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lgu0b-0007CK-Rg for bug-gnu-emacs@gnu.org; Wed, 12 May 2021 14:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 May 2021 18:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48337 X-GNU-PR-Package: emacs Original-Received: via spool by 48337-submit@debbugs.gnu.org id=B48337.162084565427583 (code B ref 48337); Wed, 12 May 2021 18:55:01 +0000 Original-Received: (at 48337) by debbugs.gnu.org; 12 May 2021 18:54:14 +0000 Original-Received: from localhost ([127.0.0.1]:40540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgtzq-0007Ap-GP for submit@debbugs.gnu.org; Wed, 12 May 2021 14:54:14 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:31252 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lgtzo-0007AW-G0 for 48337@debbugs.gnu.org; Wed, 12 May 2021 14:54:13 -0400 Original-Received: (qmail 97978 invoked by uid 3782); 12 May 2021 18:54:06 -0000 Original-Received: from acm.muc.de (p4fe15d8b.dip0.t-ipconnect.de [79.225.93.139]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 12 May 2021 20:54:05 +0200 Original-Received: (qmail 6388 invoked by uid 1000); 12 May 2021 18:54:05 -0000 Content-Disposition: inline In-Reply-To: <83cztx3v04.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:206381 Archived-At: Hello, Eli. On Tue, May 11, 2021 at 22:55:55 +0300, Eli Zaretskii wrote: > > Date: Tue, 11 May 2021 19:45:23 +0000 > > Cc: Alex Bennée , > > 48337@debbugs.gnu.org > > From: Alan Mackenzie > > > Alan, the code in nth_minibuffer and its callers is unsafe. First, > > > Fnthcdr can return nil, and then XCAR of that in nth_minibuffer > > > crashes. I fixed that now on the master branch, .... > > That Fnthcdr call "can't possibly" return nil, unless there's a bug > > somewhere. > Then the commentary of nth_minibuffer is outdated and should be > updated: it claims that returning nil is part of the contract. I will clean up this unclean coding. > > > Fset_buffer (nth_minibuffer (minibuf_level)); > > This, I think, can be justified - if read_minibuf_unwind can't find > > the minibuffer it's unwinding, we've got a serious problem and ought > > to abort Emacs ASAP. Should that, perhaps, be an explicit assert? > If you want to abort, assertions is not TRT, as it will not be > compiled in an optimized build. Call emacs_abort instead. Thanks for the tip! I now understand the immediate cause of the bug completely. Partly this is due to me seeing better backtrace information from a subsequent post from Alex. This backtrace contains: #18 0x000055e3c57335da in Frun_hooks (nargs=1, args=0x7ffe48045368) at eval.c:2701 ...... ...... #26 0x000055e3c56a82b0 in read_minibuf (map=..., initial=..., prompt=..., expflag=false, histvar=..., histpos=..., defalt=..., allow_props=false, inherit_input_method=false) at minibuf.c:683 .. The minibuf.c:683 identifies the failing point in read_minibuf as a call to record-window-buffer. r-w-b ends by calling the hook buffer-list-update-hook. At the time of calling record-window-buffer, minibuf_level has been incremented to 2, but *Minibuf-2* has not yet been created and added to minibuf.c's internal list of minibuffers. This is an inconsistent state. Something on buffer-list-update-hook calls active-minibuffer-window, and because of the inconsistent state, this crashes. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; The deeper cause of the bug is that calling buffer-list-update-hook simply doesn't belong in record-window-buffer. That hook should be called when the buffer list changes, not when a window's current buffer gets "recorded". So, as the main fix, I propose moving the call of buffer-list-update-hook to (some of) the places where record-window-buffer gets called, those places where the buffer list changes. There are exactly two such places, both in window.c. This will prevent the chain of events in read_minibuf outlined above. Also, I intend to prevent the indicated inconsistency in the minibuffer list by creating *Minibuf-2* earlier, immediately after incrementing minibuf_level to 2. And, as promised, I will tidy up the untidy and unsafe coding. Does anybody have any comments before I start hacking this? -- Alan Mackenzie (Nuremberg, Germany).