bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related)

[Alan Mackenzie <acm@muc.de>]

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!



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@muc.de> wrote:

> > Hello, Alex.

> > On Tue, May 11, 2021 at 23:07:01 +0100, Alex Bennée wrote:

> > > Alan Mackenzie <acm@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

-- 
Alan Mackenzie (Nuremberg, Germany).