GNU bug report logs - #47244
28.0.50; SIGSEGV in long-runnning Emacs

Previous Next

Package: emacs;

Reported by: Michael Welsh Duggan <md5i <at> md5i.com>

Date: Thu, 18 Mar 2021 15:40:01 UTC

Severity: normal

Found in version 28.0.50

Done: Michael Welsh Duggan <mwd <at> md5i.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> cert.org>
Cc: mwd <at> md5i.com, rudalics <at> gmx.at, 47244 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Wed, 31 Mar 2021 17:01:10 +0300
> From: Michael Welsh Duggan <mwd <at> cert.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, "mwd <at> md5i.com" <mwd <at> md5i.com>,
>         "schwab <at> linux-m68k.org" <schwab <at> linux-m68k.org>,
>         "47244 <at> debbugs.gnu.org"
>  <47244 <at> debbugs.gnu.org>
> Date: Wed, 31 Mar 2021 09:53:56 -0400
> 
> And, trapped!  Backtrace is included.  Maybe unfortunately, it isn't one
> of the new easserts, but at least we now have a different backtrace.
> Hopefully that will lead to new insights.  I will note that, in this
> instance, the reproducer did not follow the same formula, as you can see
> in the Lisp backtrace.
> 
> #0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
>         set = {
>           __val = {402653184, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 268435456, 0, 0, 93824994300624, 18446744067266838271}
>         }
>         pid = <optimized out>
>         tid = <optimized out>
> #1  0x00005555557197a1 in terminate_due_to_signal
>     (sig=6, backtrace_limit=2147483647) at ../../master/src/emacs.c:416
> #2  0x00005555557c4858 in die
>     (msg=0x55555594f2a0 "b->window_count == 0", file=0x55555594da8a "../../master/src/buffer.c", line=1969) at ../../master/src/alloc.c:7420
> #3  0x0000555555759190 in Fkill_buffer (buffer_or_name=XIL(0x555557888814))
>     at ../../master/src/buffer.c:1969
>         buffer = XIL(0x555557889325)
>         b = 0x555557889320
>         tem = XIL(0)
>         m = 0x0

So replace_buffer_in_windows didn't do its job?

Unfortunately, this assertion is _after_ we make the buffer's name
nil, so no way of knowing for sure which buffer is that, except by
looking at the Lisp which triggered that.




This bug report was last modified 4 years and 28 days ago.

Previous Next


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