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: Tue, 11 May 2021 19:45:23 +0000 Message-ID: References: <87tunasd2u.fsf@linaro.org> <83fsyu57oj.fsf@gnu.org> <838s4l5uld.fsf@gnu.org> <83zgx14cal.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="29490"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48337@debbugs.gnu.org, Alex =?UTF-8?Q?Benn=C3=A9e?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 11 21:46:13 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 1lgYKb-0007a4-Gr for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 21:46:13 +0200 Original-Received: from localhost ([::1]:49616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgYKa-0001ln-JQ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 15:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgYKQ-0001jr-Vz for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54187) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgYKQ-0003RW-OZ for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lgYKQ-000235-La for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 15:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 May 2021 19:46:02 +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.16207623317828 (code B ref 48337); Tue, 11 May 2021 19:46:02 +0000 Original-Received: (at 48337) by debbugs.gnu.org; 11 May 2021 19:45:31 +0000 Original-Received: from localhost ([127.0.0.1]:37499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgYJv-00022B-CP for submit@debbugs.gnu.org; Tue, 11 May 2021 15:45:31 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:49858 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lgYJt-00021z-Mv for 48337@debbugs.gnu.org; Tue, 11 May 2021 15:45:30 -0400 Original-Received: (qmail 35491 invoked by uid 3782); 11 May 2021 19:45:23 -0000 Original-Received: from acm.muc.de (p4fe15d8c.dip0.t-ipconnect.de [79.225.93.140]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 11 May 2021 21:45:23 +0200 Original-Received: (qmail 11268 invoked by uid 1000); 11 May 2021 19:45:23 -0000 Content-Disposition: inline In-Reply-To: <83zgx14cal.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:206284 Archived-At: Hello, Eli. On Tue, May 11, 2021 at 16:42:26 +0300, Eli Zaretskii wrote: > > From: Alex Bennée > > Date: Tue, 11 May 2021 13:54:02 +0100 > > Cc: 48337@debbugs.gnu.org, Alan Mackenzie > > (gdb) pp Vminibuffer_list > > (# #) > Thanks. > 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. Clearly there's a bug somewhere, and the fact it triggered an abort is a good thing, since it should enable us to find that bug more easily. nth_minibuffer is called only with argument DEPTH set to 0 or minibuf_level. minibuf_level is initialised to 0 and thereafter only altered at exactly 2 places, a minibuf_level++ when entering a new MB, and minibuf_level-- when exiting it. Vminibuffer_list, the list of minibuffers, is extended by one element when a new minibuffer level is entered for the first time. This is done by function get_minibuffer. Once *Minibuf-2* has been created, it is reused every time a recursive MB call at that level happens, and it is never garbage collected. My hypothesis at the moment is that minibuf_level++ has happened (setting its value to 2), but get_minibuffer(2) hasn't happened yet, so VMinibuffer_list is only 2 elements long, ( *Minibuf-0* *Minibuf-1*). Something is trying to call nth_minibuffer (minibuf_level) in that inconsistent state. There is a window of ~115 lines of code in read_minibuf where that could happen. However, Alex's dump doesn't say what the current positionn in read_minibuf is. Instead it says "lisp.h:1008", which is unhelpful in the extreme. Why does GDB have to be so "clever"? Is there any way to stop GDB doing this and make it report the actual position in the prime source code as well as the position in some inline function? I'm going to write to Alex asking him to provide more details - his posts are lacking a lisp backtrace, a recipe, and so much needed information is . Why does GDB fail to display this information? Surely it should know what processor registers the arguments and local variables are stored in, and where in the stack frame they have been pushed? > .... but there're more problems: some the callers of nth_minibuffer > don't seem to be protected from it returning nil. For example, we > have this in read_minibuf_unwind: > 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? > and this in minibuffer_unwind: > set_window_buffer (window, nth_minibuffer (0), 0, 0); This is similar: If we're unwinding a minibuffer call, *Minibuf-0* is "bound" to exist. Perhaps there should be an explicit assert here, too? > In other cases you compare windows' buffers [EZ's textual correction > incorporated] with nil, which can never be true, so a preliminary test > for nil would be nice to avoid a loop that can never find anything > useful. > Please make this code more robust. OK. I will do this. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).