GNU bug report logs -
#48337
Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related)
Previous Next
Full log
Message #80 received at 48337 <at> debbugs.gnu.org (full text, mbox):
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 <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
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 4 years and 62 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.