From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alex =?UTF-8?Q?Benn=C3=A9e?= Newsgroups: gmane.emacs.bugs Subject: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 23:35:34 +0100 Message-ID: <87o8ddc59q.fsf@linaro.org> References: <87tunasd2u.fsf@linaro.org> <83fsyu57oj.fsf@gnu.org> <87y2ckgby0.fsf@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39224"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.13; emacs 28.0.50 Cc: 48337@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 15 00:37:10 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 1lhgQf-000A1E-Rg for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 May 2021 00:37:09 +0200 Original-Received: from localhost ([::1]:50762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhgQe-0004us-Ug for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 May 2021 18:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhgQY-0004uk-Nh for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 18:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35706) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhgQY-0002rr-GN for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 18:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lhgQY-0005jw-Dn for bug-gnu-emacs@gnu.org; Fri, 14 May 2021 18:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex =?UTF-8?Q?Benn=C3=A9e?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 May 2021 22:37: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.162103177321975 (code B ref 48337); Fri, 14 May 2021 22:37:02 +0000 Original-Received: (at 48337) by debbugs.gnu.org; 14 May 2021 22:36:13 +0000 Original-Received: from localhost ([127.0.0.1]:47252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhgPk-0005iN-Dp for submit@debbugs.gnu.org; Fri, 14 May 2021 18:36:12 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:52913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lhgPi-0005iA-JR for 48337@debbugs.gnu.org; Fri, 14 May 2021 18:36:12 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id z130so459700wmg.2 for <48337@debbugs.gnu.org>; Fri, 14 May 2021 15:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=9UPhRJZiGhQYhDktO8OXthjAHt8xjWsJyUU2qkhn9Uw=; b=Lktx3soatshnJH47d0HgeXcHBZmygc42UEDnUA/CA68w9ara871f8oCUvrAnqrB30j 1vuooxC80cOWPLhnFv31MU+pyXvbDdbGtGdjevLxgQioo4isM1tZqktjF8s8x82LrUry b5ta5fwYa/QAhmzBVuu1czkWA1S+BHcMIwegWb6iZu23vIh4WTA0/MZ5zqQ059TkZZBX dO16X/PqZuBVjI3DQrH4GTpN2gssKE6OYwXHvmnwWkNkI8rGsP4EIXb5vUDVxRf0qFn4 SqEnF5zHBxqvcrd2USYVLUbyu4/uJJ3sz5pWphEi3UmVGKsyUgnX/K0i1k9d36Gz/CP9 uKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=9UPhRJZiGhQYhDktO8OXthjAHt8xjWsJyUU2qkhn9Uw=; b=WOX8G1STs9UvNtYpxxa5mUrEHuYFDYLd/cM1ulaUi6TMBSB032I1ylAgru+O2f457I BCSrUG2qZhJ6yISwEEZzRZJjzxNuBUxXFrVwrUbbPhZNGh2zX4lr4jCdpuqg1TzlPoGc noqyT18JNGnS+ZJPU1T4Jvm5YQ+1sOeqBKQlEFfCZxo9BpV3MJr6i2pOiCotcz5tHTxT Ug01bWp9Xgd5sts/6wcNLyT4nN+HmgiGBayQtyekEDjmes5XI8jZHnt2I2mrE8pbCV/N t9AROxN9aD27w6ZgUPpjPnLXDBOWC2k2E4KyOpw5oN16us04y2IjXRgq6injWA2iQveN a5xA== X-Gm-Message-State: AOAM533WbCZ4SPl5Yqjxb4w23Fo6pycnKA7ehBth5tziPxi5hhyaJppY SK8YOwH1J7HlBxI+htazGnDJRaZYkEwzeg== X-Google-Smtp-Source: ABdhPJzCCn6l/aY6RGWOcUxr5HBtRoQGHlhGesBfPhtXe2z1Nv8pqLdzZehzJcFF26LjX1XFk7ItZQ== X-Received: by 2002:a1c:1f84:: with SMTP id f126mr9730690wmf.189.1621031763549; Fri, 14 May 2021 15:36:03 -0700 (PDT) Original-Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id p20sm7424229wmq.10.2021.05.14.15.36.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 May 2021 15:36:02 -0700 (PDT) Original-Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id BE5131FF7E; Fri, 14 May 2021 23:36:01 +0100 (BST) In-reply-to: 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:206562 Archived-At: Alan Mackenzie writes: > Hello, Alex. > > On Fri, May 14, 2021 at 17:52:46 +0100, Alex Benn=C3=A9e wrote: >> Sadly not, testing with 780b1db126fcfdbb50da5c1acf24b3c6e614dd9f I got a >> crash when I tried to switch buffer. > > Thanks for the two dumps. They make it obvious what has happened. > buffer-list-update-hook is getting called before the new minibuffer has > been pushed onto the minnibuffer list. > > Could I ask you to try out the following patch which should fix that > problem. Thanks! That seems to sort out both the recent crash and the original failure mode I reported in this bug. > > > diff --git a/src/minibuf.c b/src/minibuf.c > index 428998a639..d4702ee684 100644 > --- a/src/minibuf.c > +++ b/src/minibuf.c > @@ -653,11 +653,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial,= Lisp_Object prompt, > return unbind_to (count, val); > } >=20=20 > - minibuf_level++; /* Before calling choose_minibuf_frame. */ > /* Ensure now that the latest minibuffer has been created, in case > anything happens which depends on MINNIBUF_LEVEL and > Vminibuffer_list being consistent with eachother. */ > - minibuffer =3D get_minibuffer (minibuf_level); > + minibuffer =3D get_minibuffer (minibuf_level + 1); > + minibuf_level++; /* Before calling choose_minibuf_frame. */ >=20=20 > /* Choose the minibuffer window and frame, and take action on them. */ >=20=20 > > > >> On Fri, 14 May 2021 at 17:31, Alan Mackenzie wrote: > >> > Hello, Alex. > >> > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Benn=C3=A9e wrote: > >> > > Alan Mackenzie writes: > >> > > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Benn=C3=A9e wrote: >> > > >> I can now recreate at will with a magit sequence (l o hackbox/ TA= B) >> > which >> > > >> triggers a minibuffer re-size to accommodate the list of git bran= ches: > >> > > > Could you possibly give us a precise recipe to reproduce this bug,= and >> > a >> > > > GDB backtrace with Emacs compiled with CFLAGS=3D'-O0 g3' (or simil= ar)? >> > So >> > > > much of the needed information in your large dump post has been >> > > > optimised away by the compiler. Would you please also make sure t= hat >> > > > the Lisp backtrace is at the end of the GDB backtrace. I think th= is >> > > > should happen automatically if you have an Emacs .gdbinit in the >> > > > directory where you start GDB from. > >> > I now understand what the bug was, and have just committed a patch whi= ch >> > should have fixed it. Could you please update your Emacs and test your >> > bug scenario, and either confirm to me that the bug is fixed, or say w= hat >> > is still wrong. If this has to wait until Monday that's OK, but please >> > let us know that. > >> > Then, hopefully, we can close the bug. > >> > > The later rr dumps have more symbols but didn't have the benefit of = the >> > > Emacs' .gdbinit Lips backtrace. However I'm fairly confident it's be= ing >> > > triggered by doom-modeline: > >> > The actual trigger was something on buffer-list-update-hook. That sho= uld >> > now no longer cause a problem. > >> > [ .... ] > > > >> --=20 >> Alex Benn=C3=A9e >> KVM/QEMU Hacker for Linaro > >> +bt >> #0 0x00007ffff4e955cb in raise (sig=3D6) at ../sysdeps/unix/sysv/linux/= raise.c:50 >> #1 0x0000555555728708 in terminate_due_to_signal (sig=3D6, backtrace_li= mit=3D40) at emacs.c:437 >> #2 0x000055555575daa0 in emacs_abort () at sysdep.c:2282 >> #3 0x0000555555783080 in Factive_minibuffer_window () at minibuf.c:231 >> #4 0x0000555555810a6e in funcall_subr (subr=3D0x555555e0c6c0 , numargs=3D0, args=3D0x7fffffffad70) at eval.c:3109 >> #5 0x000055555581053e in Ffuncall (nargs=3D1, args=3D0x7fffffffad68) at= eval.c:3036 >> #6 0x000055555586ad5b in exec_byte_code (bytestr=3D..., vector=3D..., m= axdepth=3D..., args_template=3D..., nargs=3D1, args=3D0x7fffffffb238) at by= tecode.c:632 >> #7 0x0000555555810d06 in fetch_and_exec_byte_code (fun=3D..., syms_left= =3D..., nargs=3D1, args=3D0x7fffffffb230) at eval.c:3160 >> #8 0x000055555581118c in funcall_lambda (fun=3D..., nargs=3D1, arg_vect= or=3D0x7fffffffb230) at eval.c:3241 >> #9 0x0000555555810592 in Ffuncall (nargs=3D2, args=3D0x7fffffffb228) at= eval.c:3040 >> #10 0x000055555586ad5b in exec_byte_code (bytestr=3D..., vector=3D..., m= axdepth=3D..., args_template=3D..., nargs=3D0, args=3D0x7fffffffb7a0) at by= tecode.c:632 >> #11 0x0000555555810d06 in fetch_and_exec_byte_code (fun=3D..., syms_left= =3D..., nargs=3D0, args=3D0x7fffffffb7a0) at eval.c:3160 >> #12 0x000055555581118c in funcall_lambda (fun=3D..., nargs=3D0, arg_vect= or=3D0x7fffffffb7a0) at eval.c:3241 >> #13 0x0000555555810592 in Ffuncall (nargs=3D1, args=3D0x7fffffffb798) at= eval.c:3040 >> #14 0x000055555580f7a4 in funcall_nil (nargs=3D1, args=3D0x7fffffffb798)= at eval.c:2677 >> #15 0x000055555580fcce in run_hook_with_args (nargs=3D1, args=3D0x7fffff= ffb798, funcall=3D0x55555580f781 ) at eval.c:2854 >> #16 0x000055555580f82a in Frun_hook_with_args (nargs=3D1, args=3D0x7ffff= fffb798) at eval.c:2719 >> #17 0x000055555580fd66 in run_hook (hook=3D...) at eval.c:2867 >> #18 0x000055555580f7e5 in Frun_hooks (nargs=3D1, args=3D0x7fffffffb8f8) = at eval.c:2701 >> #19 0x0000555555810978 in funcall_subr (subr=3D0x555555e15660 , numargs=3D1, args=3D0x7fffffffb8f8) at eval.c:3091 >> #20 0x000055555581053e in Ffuncall (nargs=3D2, args=3D0x7fffffffb8f0) at= eval.c:3036 >> #21 0x000055555580fe5b in call1 (fn=3D..., arg1=3D...) at eval.c:2896 >> #22 0x00005555557650a0 in run_buffer_list_update_hook (buf=3D0x555555f4b= a60) at buffer.c:529 >> #23 0x0000555555765504 in Fget_buffer_create (buffer_or_name=3D..., inhi= bit_buffer_hooks=3D...) at buffer.c:635 >> #24 0x0000555555785d94 in get_minibuffer (depth=3D1) at minibuf.c:1028 = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> #25 0x00005555557841fd in read_minibuf (map=3D..., initial=3D..., prompt= =3D..., expflag=3Dfalse, histvar=3D..., histpos=3D..., defalt=3D..., allow_= props=3Dfalse, inherit_input_method=3Dfalse) at minibuf.c:660 --=20 Alex Benn=C3=A9e