GNU bug report logs - #48433
28.0.50; Emacs Core Dump when trying to visit file

Previous Next

Full log

View this message in rfc822 format

From: Sébastien Le Callonnec <sebastien <at> weblogism.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 48433 <at> debbugs.gnu.org
Subject: bug#48433: 28.0.50; Emacs Core Dump when trying to visit file
Date: Sat, 15 May 2021 12:16:20 +0100

Hi Eli,

On 15/05/2021 11:40, Eli Zaretskii wrote:
>> Cc: 48433 <at> debbugs.gnu.org, acm <at> muc.de
>> From: Sébastien Le Callonnec <sebastien <at> weblogism.com>
>> Date: Sat, 15 May 2021 11:10:38 +0100
>>
>>> Thanks, but can you also provide a Lisp backtrace, by invoking
>>> "xbacktrace" from GDB?  That command is defined in src/.gdbinit.
>>>
>>
>> I am not having much luck there:
>>
>> (gdb) xbacktrace
>> 'backtrace_top' has unknown return type; cast the call to its declared
>> return type
> 
> How did you compile Emacs?  Please compile with -g3 on the compiler
> command line.


Ah, I was not using -g3, here it is:

```
(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)

```

(ok, seems to be triggered by powerline, that's why I could not create
that recipe...)

```
(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)
#3  0x00005555557ba8eb in funcall_subr (subr=0x555555c6b7e0
<Sactive_minibuffer_window>, numargs=0, args=0x7fffffffa300) at eval.c:3109
        internal_argbuf = {XIL(0x8700010000), XIL(0),
XIL(0x555555ce3da0), XIL(0x109ebdb700), XIL(0x555555c6b7e0),
XIL(0x7fffffffa258), make_fixnum(23456248679553), XIL(0x1000000000)}
        internal_args = 0x7fffffffa300
#4  0x00005555557ba4b2 in Ffuncall (nargs=1, args=0x7fffffffa2f8) at
eval.c:3036
        fun = XIL(0x555555c6b7e5)
        original_fun = XIL(0x2aaa9c0cbee0)
        funcar = XIL(0x7fffffffa2d0)
        numargs = 0
        val = XIL(0x30)
        count = 52
```

>> 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. (=


Regards,
Sébastien.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.