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


Message #278 received at 47244 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> cert.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "mwd <at> md5i.com" <mwd <at> md5i.com>,
 "47244 <at> debbugs.gnu.org" <47244 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 "schwab <at> linux-m68k.org" <schwab <at> linux-m68k.org>
Subject: Re: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 01 Apr 2021 14:30:06 -0400
martin rudalics <rudalics <at> gmx.at> writes:

>  > Okay.  I got a nice trigger from this.  I've added some extra
>  > debugging info after the backtrace.
>
> Thanks.  Nice but not amusing.  Things like that never can happen.  So
> presumably *Server* is the buffer you want to get rid off.  I can only
> add another diff based on that assumption.  Please put a breakpoint on
> that non-sensical
>
> 		  best_window = Qt;
>
> line 3050 in window.c.  When it triggers please use "s" to painfully
> step through the entire set_window_buffer and other_buffer_safely below
> and tell me whether you find something fishy: Is other_buffer_safely
> called at all and what is the name of the "buf" it returns?  Does
> set_window_buffer for some reason refuse to wset_buffer to the one
> returned by other_buffer_safely?

The answer, which I sort of suspected, is that it never hit that
breakpoint at all before the assertion fires.

-- 
Michael Welsh Duggan
(mwd <at> cert.org)




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.