bug#48433: 28.0.50; Emacs Core Dump when trying to visit file

[Eli Zaretskii]

> Cc: 48433@debbugs.gnu.org, acm@muc.de
> From: Sébastien Le Callonnec <sebastien@weblogism.com>
> Date: Sat, 15 May 2021 12:16:20 +0100
> 
> (gdb) xbacktrace
> "active-minibuffer-window" (0xffffa300)
> "minibuffer-window-active-p" (0xffffa7a0)
> "powerline-set-selected-window" (0xfffface0)
> "run-hooks" (0xffffae48)
> "read-from-minibuffer" (0xffffb318)
> "ido-read-internal" (0xffffbe30)
> "ido-file-internal" (0xffffc610)
> "ido-find-file" (0xffffce40)
> "funcall-interactively" (0xffffce38)
> "call-interactively" (0xffffcfe0)
> "command-execute" (0xffffd538)

Thanks, this clarifies the issue.

> (gdb) bt full
> #0  terminate_due_to_signal (sig=21845, backtrace_limit=1481635280) at
> emacs.c:399
> #1  0x000055555571c837 in emacs_abort () at sysdep.c:2282
> #2  0x000055555573decb in Factive_minibuffer_window () at minibuf.c:231
>         frames = XIL(0x1f1dad70d)
>         frame = make_fixnum(23456248280808)
>         f = 0x55555623e6a5
>         innermost_MB = XIL(0)

What is the value of minibuf_level in frame #2?

> >> This seems to isolate the issue to `read_minibuf_unwind`, which is part
> >> of the changeset of the commit I bisected to.
> > 
> > That was clear before, what is not clear is _where_ in
> > read_minibuf_unwind it happens, and why.  That's a very large
> > function.
> 
> Sorry if I was stating the obvious. (=

No need to be sorry, no harm done.