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

["Alex Bennée" <alex.bennee@linaro.org>]

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


-- 
Alex Bennée