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

Previous Next

Full log

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

From: Michael Welsh Duggan <mwd <at> cert.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "mwd <at> md5i.com" <mwd <at> md5i.com>,
 "47244 <at> debbugs.gnu.org" <47244 <at> debbugs.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: Mon, 29 Mar 2021 11:26:22 -0400

Michael Welsh Duggan <mwd <at> cert.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Mon, 29 Mar 2021 18:02:24 +0300
>>> From: Eli Zaretskii <eliz <at> gnu.org>
>>> Cc: mwd <at> md5i.com, schwab <at> linux-m68k.org, 47244 <at> debbugs.gnu.org
>>> 
>>> Any idea where could be the Lisp code that switches from " *nntpd*" to
>>> the buffer in the currently selected window?  Perhaps some
>>> with-current-buffer thing somewhere?
>>
>> Actually, no, I don't think it can be with-current-buffer, it must be
>> something else.  I wonder how we ended up being at top-level with
>> current buffer being " *nntpd*" and the selected window's buffer being
>> something else, which was killed?  Hmm...
>
> I'm far from certain myself.  I have no options specifically set
> regarding threads and I run Gnus from Emacs sources.  What I can say is
> that every time I can remember this happening, the following is the
> sequence of events:
>
> 1) Emacs has locked up.  This is presumably because:
>    a) I have switched my work VPN on, and
>    b) Gnus uses my existing IMAP connection to attempt to check for new
>       articles due to this clause in my .gnus file:
>
>          (gnus-demon-add-handler 'gnus-demon-scan-news 5 nil)
> 2) From the *Group* buffer I hit `C-g` to cancel its attempt, and `^` to
>    switch to the Gnus *Sever* buffer.
> 3) In that buffer I go to the imap connection and type `C O`, which runs
>    `gnus-server-close-server` and `gnus-server-open-server`,
>    respectively.
> 4) I type `q` to exit the server buffer.  This is when the breakpoint
>    triggers.  `g` calls the following function:
>
>     (defun gnus-server-exit ()
>       "Return to the group buffer."
>       (interactive nil gnus-server-mode)
>       (gnus-run-hooks 'gnus-server-exit-hook)
>       (gnus-kill-buffer (current-buffer))
>       (gnus-configure-windows 'group t))
>
> `gnus-sever-exit-hook` is nil.  The definition of `gnus-kill-buffer` is
> as follows:
>
>     (defmacro gnus-kill-buffer (buffer)
>       "Kill BUFFER and remove from the list of Gnus buffers."
>       `(let ((buf ,buffer))
>          (when (gnus-buffer-live-p buf)
>            (kill-buffer buf)
>            (gnus-prune-buffers))))
>     
>     (defun gnus-buffers ()
>       "Return a list of live Gnus buffers."
>       (setq gnus-buffers (seq-filter #'buffer-live-p gnus-buffers)))
>     
>     (defalias 'gnus-prune-buffers #'gnus-buffers)
>
> `gnus-configure-windows` is a quite complex function that I'm not going
> to attach to this email, as it is easier to look at it in-situ from the
> sources (gnus-win.el).

A further point of information.  I do have an nntp connection as well as
the imap connection.  It's an ntp connection to "news.gmane.io".  In the
sequence of events above, I do not specifically attempt to reset the
nntp connection, but it may to be affected by the VPN switch.  I do not
know what mechanism might have killed that buffer.

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

Previous Next

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