Package: emacs;
Reported by: Alex Bennée <alex.bennee <at> linaro.org>
Date: Mon, 10 May 2021 19:32:01 UTC
Severity: normal
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Alex Bennée <alex.bennee <at> linaro.org> To: Alan Mackenzie <acm <at> muc.de> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, 48337 <at> debbugs.gnu.org Subject: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Fri, 14 May 2021 23:35:34 +0100
Alan Mackenzie <acm <at> muc.de> writes: > Hello, Alex. > > On Fri, May 14, 2021 at 17:52:46 +0100, Alex Bennée 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); > } > > - 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 = get_minibuffer (minibuf_level); > + minibuffer = get_minibuffer (minibuf_level + 1); > + minibuf_level++; /* Before calling choose_minibuf_frame. */ > > /* Choose the minibuffer window and frame, and take action on them. */ > > > > >> On Fri, 14 May 2021 at 17:31, Alan Mackenzie <acm <at> muc.de> wrote: > >> > Hello, Alex. > >> > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote: > >> > > Alan Mackenzie <acm <at> muc.de> writes: > >> > > > On Tue, May 11, 2021 at 07:51:20 +0100, Alex Bennée wrote: >> > > >> I can now recreate at will with a magit sequence (l o hackbox/ TAB) >> > which >> > > >> triggers a minibuffer re-size to accommodate the list of git branches: > >> > > > Could you possibly give us a precise recipe to reproduce this bug, and >> > a >> > > > GDB backtrace with Emacs compiled with CFLAGS='-O0 g3' (or similar)? >> > So >> > > > much of the needed information in your large dump post has been >> > > > optimised away by the compiler. Would you please also make sure that >> > > > the Lisp backtrace is at the end of the GDB backtrace. I think this >> > > > 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 which >> > 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 what >> > 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 being >> > > triggered by doom-modeline: > >> > The actual trigger was something on buffer-list-update-hook. That should >> > now no longer cause a problem. > >> > [ .... ] > > > >> -- >> Alex Bennée >> KVM/QEMU Hacker for Linaro > >> +bt >> #0 0x00007ffff4e955cb in raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50 >> #1 0x0000555555728708 in terminate_due_to_signal (sig=6, backtrace_limit=40) 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=0x555555e0c6c0 <Sactive_minibuffer_window>, numargs=0, args=0x7fffffffad70) at eval.c:3109 >> #5 0x000055555581053e in Ffuncall (nargs=1, args=0x7fffffffad68) at eval.c:3036 >> #6 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x7fffffffb238) at bytecode.c:632 >> #7 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=1, args=0x7fffffffb230) at eval.c:3160 >> #8 0x000055555581118c in funcall_lambda (fun=..., nargs=1, arg_vector=0x7fffffffb230) at eval.c:3241 >> #9 0x0000555555810592 in Ffuncall (nargs=2, args=0x7fffffffb228) at eval.c:3040 >> #10 0x000055555586ad5b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x7fffffffb7a0) at bytecode.c:632 >> #11 0x0000555555810d06 in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=0, args=0x7fffffffb7a0) at eval.c:3160 >> #12 0x000055555581118c in funcall_lambda (fun=..., nargs=0, arg_vector=0x7fffffffb7a0) at eval.c:3241 >> #13 0x0000555555810592 in Ffuncall (nargs=1, args=0x7fffffffb798) at eval.c:3040 >> #14 0x000055555580f7a4 in funcall_nil (nargs=1, args=0x7fffffffb798) at eval.c:2677 >> #15 0x000055555580fcce in run_hook_with_args (nargs=1, args=0x7fffffffb798, funcall=0x55555580f781 <funcall_nil>) at eval.c:2854 >> #16 0x000055555580f82a in Frun_hook_with_args (nargs=1, args=0x7fffffffb798) at eval.c:2719 >> #17 0x000055555580fd66 in run_hook (hook=...) at eval.c:2867 >> #18 0x000055555580f7e5 in Frun_hooks (nargs=1, args=0x7fffffffb8f8) at eval.c:2701 >> #19 0x0000555555810978 in funcall_subr (subr=0x555555e15660 <Srun_hooks>, numargs=1, args=0x7fffffffb8f8) at eval.c:3091 >> #20 0x000055555581053e in Ffuncall (nargs=2, args=0x7fffffffb8f0) at eval.c:3036 >> #21 0x000055555580fe5b in call1 (fn=..., arg1=...) at eval.c:2896 >> #22 0x00005555557650a0 in run_buffer_list_update_hook (buf=0x555555f4ba60) at buffer.c:529 >> #23 0x0000555555765504 in Fget_buffer_create (buffer_or_name=..., inhibit_buffer_hooks=...) at buffer.c:635 >> #24 0x0000555555785d94 in get_minibuffer (depth=1) at minibuf.c:1028 <======================================= >> #25 0x00005555557841fd in read_minibuf (map=..., initial=..., prompt=..., expflag=false, histvar=..., histpos=..., defalt=..., allow_props=false, inherit_input_method=false) at minibuf.c:660 -- Alex Bennée
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.