[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer ac
From: |
Alex Bennée |
Subject: |
bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) |
Date: |
Fri, 14 May 2021 23:35:34 +0100 |
User-agent: |
mu4e 1.5.13; emacs 28.0.50 |
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
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), (continued)
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Gregory Heytings, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Eli Zaretskii, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Gregory Heytings, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Eli Zaretskii, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Gregory Heytings, 2021/05/15
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alan Mackenzie, 2021/05/11
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alex Bennée, 2021/05/11
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alan Mackenzie, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alex Bennée, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alan Mackenzie, 2021/05/14
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related),
Alex Bennée <=
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alan Mackenzie, 2021/05/15
- bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related), Alan Mackenzie, 2021/05/16