bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs


From: Michael Welsh Duggan
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 08 Apr 2021 13:15:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <mwd@cert.org>
>> Cc: "mwd@md5i.com" <mwd@md5i.com>,
>>         "schwab@linux-m68k.org"
>>  <schwab@linux-m68k.org>,
>>         "47244@debbugs.gnu.org" <47244@debbugs.gnu.org>
>> Date: Thu, 08 Apr 2021 12:37:41 -0400
>> 
>> >> (gdb) xlist
>> >> $16 = 0xb820
>> >> Lisp_Symbol
>> >> $17 = (struct Lisp_Symbol *) 0x555555e6e8a0 <lispsym+47136>
>> >> "quit"
>> >> ---
>> >> nil
>> >
>> > So is this the result of your typing C-g?
>> 
>> Yes.  In the scenario I have presented, this is where Emacs is
>> unresponsive (busy cursor), presumably trying to interact with a network
>> connection that has gone away to the VPN being switched on or off, and I
>> type C-g twice rapidly in succession to regain interactivity, after
>> which I would normally then attempt to manually reset the gnus
>> connections.
>
> But then the buffer being killed is not the one you reported
> originally, is it?  You said the buffer that was killed was *Server*,
> and here we see that a temporary buffer is being killed.  Am I
> confused?

You're not confused, but the situation is confusing.  There are two
kill-buffer calls that are happening.  The Vwindow_list was getting
corrupted during the first, but that corruption did not cause a
segfault, likely to that buffer (temp buffer) not being in a window.
That corruption caused a segfault in the second.  Martin's changes have
caused an assertion to happen in the first instead.

-- 
Michael Welsh Duggan
(mwd@cert.org)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]