bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

Yesterday I switched from Emacs 25 to the emacs-26 branch. With
this Gnus hangs (sometimes) when checking mail/news
(`gnus-group-get-new-news') and then C-g no longer quits -- at
least not immediately.

The hangs are for long enough for Gnome dialogs to appear saying
that Emacs is no longer responding. Eventually control comes back
to Emacs but that might be due to repeated presses of C-g.

I think, but am not yet certain, that the problem only occurs when
checking mail/news after putting Gnus back into the "plugged"
state after it has been "unplugged". For example, starting Gnus
with `M-x gnus-unplugged' and then "plugging" it with
`gnus-agent-toggle-plugged' and then checking mail/news, (maybe)
seems to create the problem right off the bat.

Once the problem occurs, it does not seem to go away: every
subsequent check for mail/news also hangs in the same way. At this
point restarting Gnus (`gnus-group-restart') does NOT fix the
problem, one has to restart Emacs to get Gnus working again.

One clue might be this warning message I'm seeing sporadically in
the *Messages* buffer when the problem happens: "Server [whatever]
previously determined to be down; not retrying". This doesn't
really make sense; just because it was "down" previously (perhaps
my laptop didn't have an Internet connection then) doesn't mean
that it won't be available now.

Note: This does not seem to be the bug [1][2] that has existed
with Gnus for several years where it hangs checking mail/news
after (for example) moving from one WiFi hotspot to another. With
that problem C-g works instantly and it's easy to understand what
state Gnus is in. (And indeed, I have a command (which closes and
re-opens servers) that works around it.) With the new problem, C-g
doesn't seem to work, and trying to understand the state of Gnus
is very confusing.

N.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16026
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16906


In GNU Emacs 26.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.17)
 of 2017-09-24 built on moondust.localdomain
Repository revision: d93301242f38d3d9aaa55899c07496f0bdecf391
Windowing system distributor 'Fedora Project', version 11.0.11903000
System Description:	Fedora release 25 (Twenty Five)

Configured using:
 'configure --without-pop 'CFLAGS=-O2 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 LCMS2

Important settings:
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  csv-field-index-mode: t
  TeX-PDF-mode: t
  diff-auto-refine-mode: t
  flyspell-mode: t
  pdf-occur-global-minor-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  display-battery-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  save-place-mode: t
  electric-pair-mode: t
  desktop-save-mode: t
  cl-old-struct-compat-mode: t
  delete-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-contacts hides ~/.emacs.d/modules/org-contacts
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-habit hides /data/projects/vc/emacs/git/emacs/lisp/org/org-habit
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-python hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-python
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-clojure hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-clojure
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-md hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-md
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-macs hides /data/projects/vc/emacs/git/emacs/lisp/org/org-macs
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-groovy hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-groovy
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-odt hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-odt
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-texinfo hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-texinfo
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-protocol hides /data/projects/vc/emacs/git/emacs/lisp/org/org-protocol
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-io hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-io
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-list hides /data/projects/vc/emacs/git/emacs/lisp/org/org-list
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-scheme hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-scheme
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob hides /data/projects/vc/emacs/git/emacs/lisp/org/ob
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-docview hides /data/projects/vc/emacs/git/emacs/lisp/org/org-docview
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-latex hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-latex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-html hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-html
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-ctags hides /data/projects/vc/emacs/git/emacs/lisp/org/org-ctags
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-src hides /data/projects/vc/emacs/git/emacs/lisp/org/org-src
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-octave hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-octave
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-w3m hides /data/projects/vc/emacs/git/emacs/lisp/org/org-w3m
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-bibtex hides /data/projects/vc/emacs/git/emacs/lisp/org/org-bibtex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-eww hides /data/projects/vc/emacs/git/emacs/lisp/org/org-eww
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-info hides /data/projects/vc/emacs/git/emacs/lisp/org/org-info
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-processing hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-processing
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-beamer hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-beamer
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-maxima hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-maxima
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-table hides /data/projects/vc/emacs/git/emacs/lisp/org/org-table
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-R hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-R
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-publish hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-publish
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-mscgen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-mscgen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-keys hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-keys
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-css hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-css
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-haskell hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-haskell
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-picolisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-picolisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-timer hides /data/projects/vc/emacs/git/emacs/lisp/org/org-timer
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-feed hides /data/projects/vc/emacs/git/emacs/lisp/org/org-feed
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-emacs-lisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-emacs-lisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-coq hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-coq
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-J hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-J
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-mhe hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mhe
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-exp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-exp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-rmail hides /data/projects/vc/emacs/git/emacs/lisp/org/org-rmail
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-attach hides /data/projects/vc/emacs/git/emacs/lisp/org/org-attach
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-lilypond hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lilypond
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-version hides /data/projects/vc/emacs/git/emacs/lisp/org/org-version
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-makefile hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-makefile
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-sql hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sql
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-lob hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lob
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-abc hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-abc
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-java hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-java
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-shell hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-shell
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-loaddefs hides /data/projects/vc/emacs/git/emacs/lisp/org/org-loaddefs
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-element hides /data/projects/vc/emacs/git/emacs/lisp/org/org-element
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ebnf hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ebnf
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-id hides /data/projects/vc/emacs/git/emacs/lisp/org/org-id
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-crypt hides /data/projects/vc/emacs/git/emacs/lisp/org/org-crypt
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org hides /data/projects/vc/emacs/git/emacs/lisp/org/org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-plot hides /data/projects/vc/emacs/git/emacs/lisp/org/org-plot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ruby hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ruby
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-matlab hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-matlab
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-lua hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lua
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ditaa hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ditaa
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-irc hides /data/projects/vc/emacs/git/emacs/lisp/org/org-irc
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-gnus hides /data/projects/vc/emacs/git/emacs/lisp/org/org-gnus
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-C hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-C
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-lint hides /data/projects/vc/emacs/git/emacs/lisp/org/org-lint
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-comint hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-comint
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-colview hides /data/projects/vc/emacs/git/emacs/lisp/org/org-colview
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-tangle hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-tangle
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-dot hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-dot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-mobile hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mobile
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-eshell hides /data/projects/vc/emacs/git/emacs/lisp/org/org-eshell
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-sass hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sass
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-gnuplot hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-gnuplot
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-icalendar hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-icalendar
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-man hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-man
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-capture hides /data/projects/vc/emacs/git/emacs/lisp/org/org-capture
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-plantuml hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-plantuml
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-footnote hides /data/projects/vc/emacs/git/emacs/lisp/org/org-footnote
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-sed hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sed
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-clock hides /data/projects/vc/emacs/git/emacs/lisp/org/org-clock
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-js hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-js
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-latex hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-latex
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-ascii hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-ascii
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ref hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ref
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-stan hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-stan
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ocaml hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ocaml
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-agenda hides /data/projects/vc/emacs/git/emacs/lisp/org/org-agenda
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-indent hides /data/projects/vc/emacs/git/emacs/lisp/org/org-indent
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-core hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-core
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-pcomplete hides /data/projects/vc/emacs/git/emacs/lisp/org/org-pcomplete
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-datetree hides /data/projects/vc/emacs/git/emacs/lisp/org/org-datetree
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-ledger hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-ledger
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-shen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-shen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-entities hides /data/projects/vc/emacs/git/emacs/lisp/org/org-entities
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-macro hides /data/projects/vc/emacs/git/emacs/lisp/org/org-macro
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-forth hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-forth
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-mouse hides /data/projects/vc/emacs/git/emacs/lisp/org/org-mouse
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-sqlite hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-sqlite
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox-org hides /data/projects/vc/emacs/git/emacs/lisp/org/ox-org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-screen hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-screen
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-asymptote hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-asymptote
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-eval hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-eval
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-archive hides /data/projects/vc/emacs/git/emacs/lisp/org/org-archive
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ox hides /data/projects/vc/emacs/git/emacs/lisp/org/ox
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-org hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-org
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-perl hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-perl
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-faces hides /data/projects/vc/emacs/git/emacs/lisp/org/org-faces
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-bbdb hides /data/projects/vc/emacs/git/emacs/lisp/org/org-bbdb
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-compat hides /data/projects/vc/emacs/git/emacs/lisp/org/org-compat
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-lisp hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-lisp
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-install hides /data/projects/vc/emacs/git/emacs/lisp/org/org-install
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-awk hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-awk
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-calc hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-calc
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/org-inlinetask hides /data/projects/vc/emacs/git/emacs/lisp/org/org-inlinetask
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-table hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-table
/home/nlj/.emacs.d/elpa/org-plus-contrib-20170917/ob-fortran hides /data/projects/vc/emacs/git/emacs/lisp/org/ob-fortran

Features:
(shadow bbdb-message emacsbug sendmail eieio-opt speedbar sb-image
ezimage dframe help-fns radix-tree smiley gnus-cite gnus-async
gnus-bcklg qp mail-extr gnus-ml disp-table hl-line mm-archive url-http
url-gw url-cache url-auth nnrss mm-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
nndraft nnmh utf-7 server pinentry epa-file network-stream nsm starttls
nnfolder bbdb-gnus bbdb-mua nnnil gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg nntp gnus-cache cl-extra help-mode
plain-tex ox-koma-letter ox-odt rng-loc rng-uri rng-parse rng-match
rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-icalendar ox-html table ox-beamer ox-latex ox-ascii ox-publish ox
latexenc preview prv-emacs font-latex tex-mode sh-script smie executable
csv-mode sort make-mode tex-buf latex tex-ispell tex-style tex-info tex
dbus xml texinfo view vc-git diff-mode map flyspell ispell pdf-occur
ibuf-ext ibuffer ibuffer-loaddefs tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local cedet pdf-isearch let-alist pdf-misc imenu
pdf-tools compile cus-edit pdf-view bookmark pp pdf-cache pdf-info tq
pdf-util org-contacts org-capture gnus-art mm-uu mml2015 mm-view
mml-smime smime dig mailcap gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc nnoo
parse-time gnus-spec gnus-int gnus-range message subr-x puny rfc822 mml
mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231
gmm-utils mailheader gnus-win gnus nnheader org-duration org-eldoc
org-w3m org-rmail org-mhe org-irc org-info org-habit org-gnus gnus-util
rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils org-docview doc-view jka-compr image-mode dired-x dired
dired-loaddefs org-bibtex bibtex org-bbdb org-agenda org-element
avl-tree generator org advice org-macro org-footnote org-pcomplete
org-list org-faces org-entities noutline outline easy-mmode org-version
ob-shell shell pcomplete ob-R ob-python ob-plantuml ob-org ob-gnuplot
ob-ditaa ob-calc calc-store calc-trail calc-ext calc calc-loaddefs
calc-macs ob-awk ob-dot ob-maxima ob-latex ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint
ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs
format-spec find-func bbdb-anniv diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs bbdb-com crm mailabbrev bbdb bbdb-site timezone
bbdb-loaddefs finder-inf tex-site info package epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars ido seq byte-opt gv bytecomp byte-compile cconv
edmacro kmacro recentf tree-widget wid-edit easymenu battery time
wheatgrass-theme paren savehist saveplace elec-pair desktop frameset
cl-loaddefs cl-lib delsel cua-base cus-start cus-load time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 682618 99606)
 (symbols 48 110174 2)
 (miscs 40 23304 3937)
 (strings 32 204611 7770)
 (string-bytes 1 6851130)
 (vectors 16 58096)
 (vector-slots 8 1048921 35174)
 (floats 8 513 884)
 (intervals 56 30122 0)
 (buffers 992 106))

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

At 11:01 -0400 on Monday 2017-09-25, N. Jackson wrote:
>
> I think, but am not yet certain, that the problem only occurs when
> checking mail/news after putting Gnus back into the "plugged"
> state after it has been "unplugged". For example, starting Gnus
> with `M-x gnus-unplugged' and then "plugging" it with
> `gnus-agent-toggle-plugged' and then checking mail/news, (maybe)
> seems to create the problem right off the bat.

No. It turns out that this is not sufficient to trigger the bug. But I
still think it might be necessary to have been in the "unplugged" state
for the bug to manifest -- I will report back with more information if
it becomes apparent.

N.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Noam Postavsky]

On Mon, Sep 25, 2017 at 11:01 AM, N. Jackson <nljlistbox2@gmail.com> wrote:
> Yesterday I switched from Emacs 25 to the emacs-26 branch. With
> this Gnus hangs (sometimes) when checking mail/news
> (`gnus-group-get-new-news') and then C-g no longer quits -- at
> least not immediately.

Does 'pkill -SIGUSR2 emacs' help? Otherwise running under gdb and
hitting C-z at the gdb terminal should give some more info.

(elisp) Error Debugging

-- User Option: debug-on-event
     If you set ‘debug-on-event’ to a special event (*note Special
     Events::), Emacs will try to enter the debugger as soon as it
     receives this event, bypassing ‘special-event-map’.  At present,
     the only supported values correspond to the signals ‘SIGUSR1’ and
     ‘SIGUSR2’ (this is the default).  This can be helpful when
     ‘inhibit-quit’ is set and Emacs is not otherwise responding.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

At 13:14 -0400 on Monday 2017-09-25, Noam Postavsky wrote:
>
> Does 'pkill -SIGUSR2 emacs' help? Otherwise running under gdb and
> hitting C-z at the gdb terminal should give some more info.
>
> (elisp) Error Debugging
>
> -- User Option: debug-on-event
>      If you set ‘debug-on-event’ to a special event (*note Special
>      Events::), Emacs will try to enter the debugger as soon as it
>      receives this event, bypassing ‘special-event-map’.  At present,
>      the only supported values correspond to the signals ‘SIGUSR1’ and
>      ‘SIGUSR2’ (this is the default).  This can be helpful when
>      ‘inhibit-quit’ is set and Emacs is not otherwise responding.

Hi Noam,

Thanks for these tips.

I'm now running under GDB but so far today the long hang isn't
happening so I haven't been able to get a backtrace during it.
Nevertheless, after putting Gnus into an unplugged state and then
putting it into the plugged state while my computer was still
disconnected from the Internet, Gnus is now in a broken state even
though I now am connected.

The problem can be easily seen in the *Server* buffer. All my nntp
servers are broken. (My local servers (nnfolder, nndraft, and my
nnimap server on localhost) are fine.)

- The nntp servers that are managed by the Agent are in an
  "offline" state even though Gnus is currently plugged (and I
  have a good Internet connection), and the `O', `C' and `R'
  (open, close, and reset all) commands have not effect. (Toggling
  the plugged/unplugged state a few times hasn't changed this
  brokenness.)

- The nntp servers that are not managed by the Agent are in a
  "denied" state and the `O', `C' and `R' (open, close, and reset
  all) commands have not effect.

And when I say these commands have no effect, they have no effect
at all. No messages are written to the *Messages* buffer even
though I have gnus-verbose and gnus-verbose-backends both set to
10. [The former setting doesn't seem to do anything (hasn't for a
year or two), but the latter normally prints the dialog with the
servers.]

That is, it seems that Gnus is not even trying to talk to these
servers.

It almost seems as if, because they were found once in the Emacs
session not to be accessible, Gnus will never try to talk to them
again until Emacs is restarted, and commands in the *Server*
buffer to open, close etc. these servers are just quietly ignored.

I will report more as I find it, maybe look at the code, possibly
step through it in the debugger. But as my every day workflow is
so much effected by this I might have to go back to Emacs 25 where
these problems don't happen.

N.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Mon, 25 Sep 2017 11:01:01 -0400
> 
> Yesterday I switched from Emacs 25 to the emacs-26 branch. With
> this Gnus hangs (sometimes) when checking mail/news
> (`gnus-group-get-new-news') and then C-g no longer quits -- at
> least not immediately.
> 
> The hangs are for long enough for Gnome dialogs to appear saying
> that Emacs is no longer responding. Eventually control comes back
> to Emacs but that might be due to repeated presses of C-g.

This could be due to the fact that Emacs 26 uses async communications
more than previous versions.

Does gnus-group-get-new-news use any of the url-* functions?  If so,
perhaps try setting url-asynchronous to nil when fetching news, to see
if that solves the problem.  Or maybe even build Emacs with
HAVE_GETADDRINFO_A undefined, and see if that helps.

(I'm not saying that these should be the solutions for this bug, just
that they might tell us whether the asynchronous communications
features are involved here.)

I think it would also help stepping through the failing functions with
a debugger and seeing which parts of them fail.

Thanks.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Mon, 25 Sep 2017 11:01:01 -0400
>> 
>> Yesterday I switched from Emacs 25 to the emacs-26 branch. With
>> this Gnus hangs (sometimes) when checking mail/news
>> (`gnus-group-get-new-news') and then C-g no longer quits -- at
>> least not immediately.
>> 
>> The hangs are for long enough for Gnome dialogs to appear saying
>> that Emacs is no longer responding. Eventually control comes back
>> to Emacs but that might be due to repeated presses of C-g.
>
> This could be due to the fact that Emacs 26 uses async communications
> more than previous versions.
>
> Does gnus-group-get-new-news use any of the url-* functions?  If so,
> perhaps try setting url-asynchronous to nil when fetching news, to see
> if that solves the problem.  Or maybe even build Emacs with
> HAVE_GETADDRINFO_A undefined, and see if that helps.

FWIW, I would put money on `nntp-open-connection' being the culprit,
specifically the call to `open-network-stream'. I used to have similar
problems with Gnus connections hanging (including the need to restart
Emacs entirely to "clear" it out), and all my attempts at figuring it
out led me there. Unfortunately Gnus has been behaving pretty well for
me for the past six months to a year, so I might not be much more help
than that. But I remember being suspicious that these problems were
happening right around the time people seemed to be messing with the
behavior of gnutls. Could be a total red herring, though.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

At 08:20 -0700 on Friday 2017-09-29, Eric Abrahamsen wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> Does gnus-group-get-new-news use any of the url-* functions? If
>> so, perhaps try setting url-asynchronous to nil when fetching
>> news, to see if that solves the problem. Or maybe even build
>> Emacs with HAVE_GETADDRINFO_A undefined, and see if that helps.
>
> FWIW, I would put money on `nntp-open-connection' being the
> culprit, specifically the call to `open-network-stream'.

Eli and Eric, than you for these suggestions. I will have a look
in these directions the next time Gnus "breaks". (I hadn't yet
read them when I wrote the report below.)

Gnus "broke" again this morning. (It seems to break in the morning
when I switch it to the "plugged" state after I've have it
"unplugged" over night for offline reading.)

Unfortunately there are at least two different problems, although
they might be related.

(The following all applies to the Emacs session this morning with
Gnus in it's "broken" state.)

I set `debug-on-error' and got the following (redacted) backtrace
when fetching mail/news:

  Debugger entered--Lisp error: (error "something.com/443 Name or service not known")
    signal(error ("something.com/443 Name or service not known"))
    nnrss-fetch("https://something.com/boards/forums/support.246/index.rss")
    nnrss-check-group("Something Forums: Support" "")
    nnrss-retrieve-groups(("Something Forums: Support" "Something Forums: Software" "Something Forums: Something Else" "Something Forums: Discussions" "Something Forums: News") "")
    gnus-retrieve-groups(("Something Forums: Support" "Something Forums: Software" "Something Forums: Something Else" "Something Forums: Discussions" "Something Forums: News") (nnrss ""))
    gnus-read-active-file-2(("Something Forums: Support" "Something Forums: Software" "Something Forums: Something Else" "Something Forums: Discussions" "Something Forums: News") (nnrss ""))
    gnus-read-active-for-groups((nnrss "") (("nnrss:Something Forums: Support" 3 ((1 . 9)) ((unexist) (seen (1 . 6))) (nnrss "")) ("nnrss:Something Forums: Software" 3 ((1 . 1)) ((unexist) (seen 1)) (nnrss "")) ("nnrss:Something Forums: Something Else" 3 ((1 . 117)) ((unexist) (seen (1 . 56) (67 . 117))) (nnrss "")) ("nnrss:Something Forums: Discussions" 3 ((1 . 857)) ((unexist) (seen (1 . 245) (421 . 857))) (nnrss "")) ("nnrss:Something Forums: News" 3 ((1 . 672)) ((unexist) (seen (1 . 168) (282 . 672))) (nnrss ""))) nil)
    gnus-get-unread-articles(nil nil nil)
    gnus-group-get-new-news(nil)
    funcall-interactively(gnus-group-get-new-news nil)
    call-interactively(gnus-group-get-new-news nil nil)
    command-execute(gnus-group-get-new-news)

There was no problem with the reported URl; I could open it fine
in a web browser. I changed the "level" of these RSS groups so
that Gnus does not try to check them when it fetches mail and
news. After doing that, I no longer end up in the debugger when
fetching mail/news with `debug-on-error' set. That was the first
problem.

However, fetching mail/news was still broken -- no hang this time,
just nothing seeming to happen. And the *Server* buffer was messed
up as I previously described:

At 10:13 -0400 on Tuesday 2017-09-26, N. Jackson wrote:
>
> The problem can be easily seen in the *Server* buffer. All my
> nntp servers are broken.
>
> - The nntp servers that are managed by the Agent are in an
>   "offline" state even though Gnus is currently plugged (and I
>   have a good Internet connection), and the `O', `C' and `R'
>   (open, close, and reset all) commands have not effect. (Toggling
>   the plugged/unplugged state a few times hasn't changed this
>   brokenness.)
>
> - The nntp servers that are not managed by the Agent are in a
>   "denied" state and the `O', `C' and `R' (open, close, and reset
>   all) commands have not effect.

It almost seems as if Gnus is in an "unplugged" state even though
in the mode line it says that it's "plugged". (Toggling the
plugged/unplugged state so that the mode line says it's
"unplugged" doesn't help though.)

One reason why I think Gnus is actually "unplugged" is that when I
enter a news group that is managed by the Agent when Gnus is
"unplugged", the *Summary* buffer is displayed almost instantly.
In contrast when Gnus is not in a "broken" state and is "plugged",
loading the *Summary* buffer is slow as Gnus will retrieve headers
over the Internet,

A second reason why I think Gnus is actually "unplugged" is that
there are lines in news group *Summary* buffers like

  - .│0.0k│1969-12-31 19:00│ ▣ Gnus Agent               [Undownloaded article 218857]

which I would normally only see when Gnus is "unplugged".

I have now restarted Emacs to get Gnus back into a working state
-- I have to get real work done. I will report more when I have
time to investigate a "broken" instance of Gnus more thoroughly.

N.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eric Abrahamsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> At 08:20 -0700 on Friday 2017-09-29, Eric Abrahamsen wrote:
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> Does gnus-group-get-new-news use any of the url-* functions? If
>>> so, perhaps try setting url-asynchronous to nil when fetching
>>> news, to see if that solves the problem. Or maybe even build
>>> Emacs with HAVE_GETADDRINFO_A undefined, and see if that helps.
>>
>> FWIW, I would put money on `nntp-open-connection' being the
>> culprit, specifically the call to `open-network-stream'.
>
> Eli and Eric, than you for these suggestions. I will have a look
> in these directions the next time Gnus "breaks". (I hadn't yet
> read them when I wrote the report below.)

[...]

>   Debugger entered--Lisp error: (error "something.com/443 Name or service not known")
>     signal(error ("something.com/443 Name or service not known"))
>     nnrss-fetch("https://something.com/boards/forums/support.246/index.rss")

My suggestion was probably a red herring after all -- nnrss-fetch
does indeed end up calling url-* functions.

[...]

> However, fetching mail/news was still broken -- no hang this time,
> just nothing seeming to happen. And the *Server* buffer was messed
> up as I previously described:

No clue here, unfortunately.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Fri, 29 Sep 2017 13:27:35 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 28596@debbugs.gnu.org
> 
> At 10:13 -0400 on Tuesday 2017-09-26, N. Jackson wrote:
> >
> > The problem can be easily seen in the *Server* buffer. All my
> > nntp servers are broken.
> >
> > - The nntp servers that are managed by the Agent are in an
> >   "offline" state even though Gnus is currently plugged (and I
> >   have a good Internet connection), and the `O', `C' and `R'
> >   (open, close, and reset all) commands have not effect. (Toggling
> >   the plugged/unplugged state a few times hasn't changed this
> >   brokenness.)
> >
> > - The nntp servers that are not managed by the Agent are in a
> >   "denied" state and the `O', `C' and `R' (open, close, and reset
> >   all) commands have not effect.
> 
> It almost seems as if Gnus is in an "unplugged" state even though
> in the mode line it says that it's "plugged". (Toggling the
> plugged/unplugged state so that the mode line says it's
> "unplugged" doesn't help though.)
> 
> One reason why I think Gnus is actually "unplugged" is that when I
> enter a news group that is managed by the Agent when Gnus is
> "unplugged", the *Summary* buffer is displayed almost instantly.
> In contrast when Gnus is not in a "broken" state and is "plugged",
> loading the *Summary* buffer is slow as Gnus will retrieve headers
> over the Internet,
> 
> A second reason why I think Gnus is actually "unplugged" is that
> there are lines in news group *Summary* buffers like
> 
>   - .│0.0k│1969-12-31 19:00│ ▣ Gnus Agent               [Undownloaded article 218857]
> 
> which I would normally only see when Gnus is "unplugged".
> 
> I have now restarted Emacs to get Gnus back into a working state
> -- I have to get real work done. I will report more when I have
> time to investigate a "broken" instance of Gnus more thoroughly.

Any news on this?  Is this problem still present in the Emacs 26.0.90
pretest?

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

Hello Eli,

At 19:40 +0200 on Saturday 2017-12-02, Eli Zaretskii wrote:
>
> Any news on this? Is this problem still present in the Emacs
> 26.0.90 pretest?

Yes, the problem is still present with the 26.0.90 pretest. I ran
that for three weeks and the problem happened almost every day.

Then I went back to using Emacs 25 out of frustration.

No, sorry, no news. I wasn't able to get any traction on debugging
it; that would be so much easier if the code were in C! (I am
perennially unsuccessful when I try to get the Elisp debugger to
function the way I think it ought to, probably because I don't
understand the way it is supposed to work.)

However, I had forgotten (or never saw) your suggestions to

  "try setting url-asynchronous to nil when fetching news... [o]r
  maybe even build Emacs with HAVE_GETADDRINFO_A undefined"

and I will try that with 26.0.90 these next days.

Additionally, I am almost convinced that the problem is that Gnus
gets into an ambiguous state where part of it thinks it is
"unplugged" and part of it thinks it's "plugged", and that it
never even tries to retrieve the news in the cases where it seems
to be "broken".

Furthermore, I now believe that the hang that I had been observing
was just Bug 16026 / Bug 16906 and that I failed to recognise it
because I was too confused by the strange behaviour resulting from
this current bug.

N.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> Date: Mon, 04 Dec 2017 12:14:51 -0500
> 
> Hello Eli,
> 
> At 19:40 +0200 on Saturday 2017-12-02, Eli Zaretskii wrote:
> >
> > Any news on this? Is this problem still present in the Emacs
> > 26.0.90 pretest?
> 
> Yes, the problem is still present with the 26.0.90 pretest. I ran
> that for three weeks and the problem happened almost every day.
> 
> Then I went back to using Emacs 25 out of frustration.
> 
> No, sorry, no news. I wasn't able to get any traction on debugging
> it; that would be so much easier if the code were in C! (I am
> perennially unsuccessful when I try to get the Elisp debugger to
> function the way I think it ought to, probably because I don't
> understand the way it is supposed to work.)
> 
> However, I had forgotten (or never saw) your suggestions to
> 
>   "try setting url-asynchronous to nil when fetching news... [o]r
>   maybe even build Emacs with HAVE_GETADDRINFO_A undefined"
> 
> and I will try that with 26.0.90 these next days.
> 
> Additionally, I am almost convinced that the problem is that Gnus
> gets into an ambiguous state where part of it thinks it is
> "unplugged" and part of it thinks it's "plugged", and that it
> never even tries to retrieve the news in the cases where it seems
> to be "broken".
> 
> Furthermore, I now believe that the hang that I had been observing
> was just Bug 16026 / Bug 16906 and that I failed to recognise it
> because I was too confused by the strange behaviour resulting from
> this current bug.

Lars, can you help us here?  I'd hate to release Emacs 26.1 with this
annoying problem.  Can we do something to have a solution or at least
a reasonably convenient band-aid?

Thanks.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eli Zaretskii]

Ping!

> Date: Mon, 04 Dec 2017 19:56:43 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eric@ericabrahamsen.net, 28596@debbugs.gnu.org
> 
> > From: nljlistbox2@gmail.com (N. Jackson)
> > Cc: eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> > Date: Mon, 04 Dec 2017 12:14:51 -0500
> > 
> > Hello Eli,
> > 
> > At 19:40 +0200 on Saturday 2017-12-02, Eli Zaretskii wrote:
> > >
> > > Any news on this? Is this problem still present in the Emacs
> > > 26.0.90 pretest?
> > 
> > Yes, the problem is still present with the 26.0.90 pretest. I ran
> > that for three weeks and the problem happened almost every day.
> > 
> > Then I went back to using Emacs 25 out of frustration.
> > 
> > No, sorry, no news. I wasn't able to get any traction on debugging
> > it; that would be so much easier if the code were in C! (I am
> > perennially unsuccessful when I try to get the Elisp debugger to
> > function the way I think it ought to, probably because I don't
> > understand the way it is supposed to work.)
> > 
> > However, I had forgotten (or never saw) your suggestions to
> > 
> >   "try setting url-asynchronous to nil when fetching news... [o]r
> >   maybe even build Emacs with HAVE_GETADDRINFO_A undefined"
> > 
> > and I will try that with 26.0.90 these next days.
> > 
> > Additionally, I am almost convinced that the problem is that Gnus
> > gets into an ambiguous state where part of it thinks it is
> > "unplugged" and part of it thinks it's "plugged", and that it
> > never even tries to retrieve the news in the cases where it seems
> > to be "broken".
> > 
> > Furthermore, I now believe that the hang that I had been observing
> > was just Bug 16026 / Bug 16906 and that I failed to recognise it
> > because I was too confused by the strange behaviour resulting from
> > this current bug.
> 
> Lars, can you help us here?  I'd hate to release Emacs 26.1 with this
> annoying problem.  Can we do something to have a solution or at least
> a reasonably convenient band-aid?
> 
> Thanks.

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Furthermore, I now believe that the hang that I had been observing
>> was just Bug 16026 / Bug 16906 and that I failed to recognise it
>> because I was too confused by the strange behaviour resulting from
>> this current bug.
>
> Lars, can you help us here?  I'd hate to release Emacs 26.1 with this
> annoying problem.  Can we do something to have a solution or at least
> a reasonably convenient band-aid?

If `C-g' doesn't quit, it sounds a lot like the bug I reported the
other, er, year about TLS negotiation hanging Emacs if we're making
several connections at once.

I thought that was being worked at by... someone... who was fixing up
various things in accept-process-output, so I was waiting for that to
shake out before looking into it further...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Lars Ingebrigtsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> Furthermore, I might have been inaccurate when I reported that C-g
> didn't quit at all. I might have not waited long enough. On a
> later hang when I waited after pressing C-g, Emacs came back after
> about two minutes.

C-g should quit Gnus' operations immediately.  The "came back after two
minutes" is the typical thing you see on the TLS hang scenario -- I
think Emacs comes unstuck when the server closes the connection (due to
no traffic).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> Date: Thu, 28 Dec 2017 13:07:39 +0100
> 
> nljlistbox2@gmail.com (N. Jackson) writes:
> 
> > Furthermore, I might have been inaccurate when I reported that C-g
> > didn't quit at all. I might have not waited long enough. On a
> > later hang when I waited after pressing C-g, Emacs came back after
> > about two minutes.
> 
> C-g should quit Gnus' operations immediately.  The "came back after two
> minutes" is the typical thing you see on the TLS hang scenario -- I
> think Emacs comes unstuck when the server closes the connection (due to
> no traffic).

So what would be the best way of making progress with this bug?

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So what would be the best way of making progress with this bug?

What happened to the patch set to fix various irregularities with
accept-process-output that was going around the other month?  Was it
merged?  I was kinda waiting for that to go in to see whether that made
everything work before poking into this any further...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nljlistbox2@gmail.com,  eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> Date: Thu, 28 Dec 2017 17:29:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So what would be the best way of making progress with this bug?
> 
> What happened to the patch set to fix various irregularities with
> accept-process-output that was going around the other month?  Was it
> merged?  I was kinda waiting for that to go in to see whether that made
> everything work before poking into this any further...

You mean the thread Re: wait_reading_process_ouput hangs in certain
cases (w/ patches)?  We are still waiting for the updated version of
the patch (I've just sent a reminder).

But in any case, that patch was for master, not the release branch.
We could see if it also fixes this problem, and maybe consider
backporting if it does.  But I hoped there could be a safer fix for
this bug.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean the thread Re: wait_reading_process_ouput hangs in certain
> cases (w/ patches)?

Yup.

> We are still waiting for the updated version of the patch (I've just
> sent a reminder).

Right.

> But in any case, that patch was for master, not the release branch.
> We could see if it also fixes this problem, and maybe consider
> backporting if it does.  But I hoped there could be a safer fix for
> this bug.

There might be some way to mitigate this -- I haven't looked into it at
all beyond stracing a bit when Emacs hangs...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 19:54 +0200 on Thursday 2017-12-28, Eli Zaretskii wrote:
>
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: nljlistbox2@gmail.com,  eric@ericabrahamsen.net,  28596@debbugs.gnu.org
>> Date: Thu, 28 Dec 2017 17:29:34 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So what would be the best way of making progress with this bug?
>> 
>> What happened to the patch set to fix various irregularities with
>> accept-process-output that was going around the other month?  Was it
>> merged?  I was kinda waiting for that to go in to see whether that made
>> everything work before poking into this any further...
>
> You mean the thread Re: wait_reading_process_ouput hangs in certain
> cases (w/ patches)?  We are still waiting for the updated version of
> the patch (I've just sent a reminder).
>
> But in any case, that patch was for master, not the release branch.
> We could see if it also fixes this problem, and maybe consider
> backporting if it does.  But I hoped there could be a safer fix for
> this bug.

I do not think that this bug (with the ambiguous Gnus
plugged/unplugged state) is the same as the
wait_reading_process_output bug, and I'm not entirely convinced
that the two bugs are related, but of course I might be missing
something.

I can now reproduce this bug (#28596) at will -- and without any
apparent hang at all. So I think the hang I was experiencing while
trying to get Gnus to behave itself was a red herring -- quite
possibly I was running into the other bug while I was trying to
get myself out of this one.

And IIUC the wait_reading_process_output bug has been in Emacs for
a while (forever?) whereas this bug exists in Emacs 26 but I have
never seen it and cannot reproduce in Emacs 25.

N.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Thu, 28 Dec 2017 19:14:24 -0500
> Cc: eric@ericabrahamsen.net, Eli Zaretskii <eliz@gnu.org>,
>  28596@debbugs.gnu.org
> 
> I do not think that this bug (with the ambiguous Gnus
> plugged/unplugged state) is the same as the
> wait_reading_process_output bug, and I'm not entirely convinced
> that the two bugs are related, but of course I might be missing
> something.
> 
> I can now reproduce this bug (#28596) at will -- and without any
> apparent hang at all. So I think the hang I was experiencing while
> trying to get Gnus to behave itself was a red herring -- quite
> possibly I was running into the other bug while I was trying to
> get myself out of this one.
> 
> And IIUC the wait_reading_process_output bug has been in Emacs for
> a while (forever?) whereas this bug exists in Emacs 26 but I have
> never seen it and cannot reproduce in Emacs 25.

Does the problem still exist on the current emacs-26 branch?

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 20:55 +0300 on Monday 2018-07-02, Eli Zaretskii wrote:
>
> Does the problem still exist on the current emacs-26
> branch?

It exists in the released version of Emacs 26.1, but I have
only seen it there once even though I use it as my every-day
Emacs.

What I wrote about being able to reproduce it at will seems
not to have been true. It seems to depend on the day, and I
suspect it is something to do with a network or server state
that is confusing Gnus.

The last time it happened I noticed that Gmane was
unreachable from a web browser, which might be related.
(Many of my Gnus groups are on Gmane.)

I haven't used the emacs-26 branch since 26.1 was released
so I cannot answer your question directly.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: larsi@gnus.org,  eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> Date: Mon, 02 Jul 2018 20:19:24 -0400
> 
> I haven't used the emacs-26 branch since 26.1 was released
> so I cannot answer your question directly.

Is it possible for you to try the branch?  I think it's important to
know whether this problem still exists on the release branch.

Thanks.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 19:50 +0300 on Wednesday 2018-07-04, Eli Zaretskii wrote:
>
>> From: nljlistbox2@gmail.com (N. Jackson)
>> Date: Mon, 02 Jul 2018 20:19:24 -0400
>> 
>> I haven't used the emacs-26 branch since 26.1 was released so
>> I cannot answer your question directly.
>
> Is it possible for you to try the branch? I think it's
> important to know whether this problem still exists on the
> release branch.

Certainly. I have just built the emacs-26 branch [1] and I will
use it as my every-day Emacs from now on.

I'm not sure if we'll learn anything though, given that I've
only seen the problem once in 26.1 which I have been running
almost since the day it was announced. But if I do see it again
I will report back of course.

OT: Are the "potential null pointer dereference" warnings
normal? I don't think I've noticed those before today's build.
For example:

  In file included from keyboard.c:25:0:
  keyboard.c: In function ‘reorder_modifiers’:
  lisp.h:377:40: warning: potential null pointer dereference [-Wnull-dereference]
   #define lisp_h_XCDR(c) XCONS (c)->u.s.u.cdr
                          ~~~~~~~~~~~~~~~~^~
  lisp.h:1308:10: note: in expansion of macro ‘lisp_h_XCDR’
     return lisp_h_XCDR (c);
            ^~~~~~~~~~~
  lisp.h:376:38: warning: potential null pointer dereference [-Wnull-dereference]
   #define lisp_h_XCAR(c) XCONS (c)->u.s.car
                          ~~~~~~~~~~~~~~^~
  lisp.h:1302:10: note: in expansion of macro ‘lisp_h_XCAR’
     return lisp_h_XCAR (c);
            ^~~~~~~~~~~

Thanks.

N.

[1] Repository revision: 3bbd4ffc68bcc2b3e003a2179a508b82055ad770

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 14:03 -0400 on Wednesday 2018-07-04, N. Jackson wrote:
>
> At 19:50 +0300 on Wednesday 2018-07-04, Eli Zaretskii wrote:
>>
>>> From: nljlistbox2@gmail.com (N. Jackson)
>>> Date: Mon, 02 Jul 2018 20:19:24 -0400
>>> 
>>> I haven't used the emacs-26 branch since 26.1 was released so
>>> I cannot answer your question directly.
>>
>> Is it possible for you to try the branch? I think it's
>> important to know whether this problem still exists on the
>> release branch.
>
> Certainly. I have just built the emacs-26 branch [1] and I will
> use it as my every-day Emacs from now on.

> [1] Repository revision: 3bbd4ffc68bcc2b3e003a2179a508b82055ad770

Due to a thinko, that was master I built! Sorry. I will build the
emacs-26 branch now and use it as my every-day Emacs!

N.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: eric@ericabrahamsen.net,  larsi@gnus.org,  28596@debbugs.gnu.org
> Date: Wed, 04 Jul 2018 14:13:37 -0400
> 
> I will build the emacs-26 branch now and use it as my every-day
> Emacs!

Thanks.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 14:13 -0400 on Wednesday 2018-07-04, N. Jackson wrote:

> At 14:03 -0400 on Wednesday 2018-07-04, N. Jackson wrote:
>>
>> At 19:50 +0300 on Wednesday 2018-07-04, Eli Zaretskii wrote:
>>>
>>>> From: nljlistbox2@gmail.com (N. Jackson)
>>>> Date: Mon, 02 Jul 2018 20:19:24 -0400
>>>> 
>>>> I haven't used the emacs-26 branch since 26.1 was released
>>>> so I cannot answer your question directly.
>>>
>>> Is it possible for you to try the branch? I think it's
>>> important to know whether this problem still exists on the
>>> release branch.
>>
>> Certainly. I have just built the emacs-26 branch [1] and I
>> will use it as my every-day Emacs from now on.
>
>> [1] Repository revision: 3bbd4ffc68bcc2b3e003a2179a508b82055ad770
>
> Due to a thinko, that was master I built! Sorry. I will build
> the emacs-26 branch now and use it as my every-day Emacs!
>
> N.

I have really built the emacs-26 branch [1] this time!

As promised, I will use it from now on as my every-day Emacs and
report back here if I see the bug again.

OT: Compared to the five "potential null pointer derefernce"
warnings on master there is only one on emacs-26. Is this
normal? (It feels to me as if one is one too many.)

  indent.c: In function ‘scan_for_column’:
  indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
     return 0;
            ^
  indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
  indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
  indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]


[1] Repository revision: 0dce5e59206db7bd0b9cd43ae712272105300ae4

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: eric@ericabrahamsen.net,  larsi@gnus.org,  28596@debbugs.gnu.org
> Date: Wed, 04 Jul 2018 14:38:46 -0400
> 
> OT: Compared to the five "potential null pointer derefernce"
> warnings on master there is only one on emacs-26. Is this
> normal? (It feels to me as if one is one too many.)
> 
>   indent.c: In function ‘scan_for_column’:
>   indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
>      return 0;
>             ^
>   indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
>   indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]
>   indent.c:69:10: warning: potential null pointer dereference [-Wnull-dereference]

This one is known, and we've decided it is a GCC bug.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

At 14:38 -0400 on Wednesday 2018-07-04, N. Jackson wrote:
>
>>> At 19:50 +0300 on Wednesday 2018-07-04, Eli Zaretskii wrote:
>>>>
>>>> Is it possible for you to try the branch? I think it's
>>>> important to know whether this problem still exists on the
>>>> release branch.

> I have really built the emacs-26 branch [1] this time!
>
> As promised, I will use it from now on as my every-day Emacs and
> report back here if I see the bug again.
>
> [1] Repository revision: 0dce5e59206db7bd0b9cd43ae712272105300ae4

Yes, the problem still exists. Gnus got into the confused
plugged/unplugged state again this morning.

FWIW:

M-x emacs-uptime RET
==> 5 days, 0 hours, 26 minutes, 55 seconds

Memory information:
((conses 16 1153669 478417)
 (symbols 48 121724 355)
 (miscs 40 24187 11415)
 (strings 32 308736 20050)
 (string-bytes 1 12884595)
 (vectors 16 74179)
 (vector-slots 8 2504362 73640)
 (floats 8 2016 1881)
 (intervals 56 41378 48502)
 (buffers 992 323))

After Gnus got into the confused state and after trying for several
minutes to get it back to it's senses, I exited Gnus (but not Emacs) and
restarted Gnus (with M-x gnus RET) and it was still in it's stuck state
and it printed these messages as it started:

  20180712T104052.549> Reading /home/nlj/.newsrc.eld...
  20180712T104052.735> Opening nnfolder server on archive...
  20180712T104052.736> Opening nnfolder server on archive...done
  20180712T104052.737> Opening nntp server on nntp.olduse.net...
  20180712T104132.771> Opening nntp server on nntp.olduse.net...failed: >>> (error nntp.olduse.net/nntp Name or service not known)
  20180712T104132.772> Opening nntp server on nntp.aioe.org...
  20180712T104212.811> Opening nntp server on nntp.aioe.org...done
  20180712T104212.811> Opening nntp server on dusty...
  20180712T104252.851> Opening nntp server on dusty...failed: >>> (error news.gmane.org/nntp Name or service not known)
  20180712T104252.852> Opening nntp server on news.gmane.org...
  20180712T104332.887> Opening nntp server on news.gmane.org...done
  20180712T104332.887> Opening nnimap server on Local Dovecot Mailstore...
  20180712T104332.888> Opening connection to localhost via tls...
  20180712T104333.079> Opening connection to localhost...done
  20180712T104333.080> Opening nnimap server on Local Dovecot Mailstore...done
  20180712T104333.144> No new newsgroups
  20180712T104333.161> Checking new news...
  20180712T104333.164> Reading active file via nnnil...
  20180712T104333.164> Reading active file via nnnil...
  20180712T104333.164> Reading active file via nnnil...done
  20180712T104333.164> Reading active file from nntp.olduse.net via nntp...
  20180712T104333.164> Opening nntp server on nntp.olduse.net...
  20180712T104333.165> Server nntp+nntp.olduse.net previously determined to be down; not retrying
  20180712T104333.165> Opening nntp server on nntp.olduse.net...failed: >>> (error news.gmane.org/nntp Name or service not known)
  20180712T104333.192> Opening nntp server on nntp.aioe.org...
  20180712T104333.193> Opening nntp server on nntp.aioe.org...done
  20180712T104333.194> Opening nntp server on news.gmane.org...
  20180712T104333.195> Opening nntp server on news.gmane.org...done
  20180712T104333.201> nnimap read 0k from localhost
  20180712T104333.408> Reading active file from archive via nnfolder...
  20180712T104333.409> Opening nnfolder server on archive...
  20180712T104333.410> Opening nnfolder server on archive...done
  20180712T104333.410> Reading active file from archive via nnfolder...
  20180712T104333.411> Reading active file from archive via nnfolder...done
  20180712T104333.412> Reading active file via nnfolder...
  20180712T104333.412> Opening nnfolder server...
  20180712T104333.413> Opening nnfolder server...done
  20180712T104333.440> Reading incoming mail from file...
  20180712T104333.441> nnfolder: Reading incoming mail (no new mail)...done
  20180712T104333.442> Reading active file via nnfolder...
  20180712T104333.443> Reading active file via nnfolder...done
  20180712T104333.443> Reading active file via nndraft...
  20180712T104333.446> Reading active file via nndraft...
  20180712T104333.447> Reading active file via nndraft...done
  20180712T104333.448> Checking new news...done
  Warning: Opening nntp server on nntp.olduse.net...failed: >>> (error news.gmane.org/nntp Name or service not known); Server nntp+nntp.olduse.net previously determined to be down; not retrying; Opening nntp server on dusty...failed: >>> (error news.gmane.org/nntp Name or service not known); Opening nntp server on nntp.olduse.net...failed: >>> (error nntp.olduse.net/nntp Name or service not known)

The errors for olduse.net happen all the time (I suspect the site has
gone away), so I assume they are unrelated, but the second message at
20180712T104333.165 seems odd: it appears to suggest that it was
checking olduse.net and gmane.org failed. Or maybe I'm just not reading
that right.

[The server I have set up with the name of "dusty" is on gmane, so the
messages about gmane not being known when checking dusty do make sense.]

I then exited Gnus and exited Emacs, restarted Emacs, restarted Gnus and
everything was back to working as normal.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: eric@ericabrahamsen.net,  larsi@gnus.org,  28596@debbugs.gnu.org
> Date: Thu, 12 Jul 2018 11:33:32 -0400
> 
> Yes, the problem still exists. Gnus got into the confused
> plugged/unplugged state again this morning.

Thanks.  I hope the Gnus developers will look into this.

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Lars Ingebrigtsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> Yes, the problem still exists. Gnus got into the confused
> plugged/unplugged state again this morning.

I've skimmed this thread -- the original bug was about `C-g' not working
when Gnus hangs.  I think this has likely been fixed -- Gnus now binds
`inhibit-quit' to nil when bits of Gnus are running off of a timer.  (In
Emacs 27.)

Do you see these problems in Emacs 27?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> nljlistbox2@gmail.com (N. Jackson) writes:
>
>> Yes, the problem still exists. Gnus got into the confused
>> plugged/unplugged state again this morning.
>
> I've skimmed this thread -- the original bug was about `C-g' not working
> when Gnus hangs.  I think this has likely been fixed -- Gnus now binds
> `inhibit-quit' to nil when bits of Gnus are running off of a timer.  (In
> Emacs 27.)
>
> Do you see these problems in Emacs 27?

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28596: 26.0.60; Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Cc: larsi@gnus.org,  eric@ericabrahamsen.net,  28596@debbugs.gnu.org
> Date: Wed, 04 Jul 2018 14:03:17 -0400
> 
> OT: Are the "potential null pointer dereference" warnings
> normal? I don't think I've noticed those before today's build.

Please report them in a separate bug.  Mostly they are GCC bugs, but
once in a blue moon we find a real problem.

> For example:
> 
>   In file included from keyboard.c:25:0:
>   keyboard.c: In function ‘reorder_modifiers’:
>   lisp.h:377:40: warning: potential null pointer dereference [-Wnull-dereference]
>    #define lisp_h_XCDR(c) XCONS (c)->u.s.u.cdr
>                           ~~~~~~~~~~~~~~~~^~
>   lisp.h:1308:10: note: in expansion of macro ‘lisp_h_XCDR’
>      return lisp_h_XCDR (c);
>             ^~~~~~~~~~~
>   lisp.h:376:38: warning: potential null pointer dereference [-Wnull-dereference]
>    #define lisp_h_XCAR(c) XCONS (c)->u.s.car
>                           ~~~~~~~~~~~~~~^~
>   lisp.h:1302:10: note: in expansion of macro ‘lisp_h_XCAR’
>      return lisp_h_XCAR (c);
>             ^~~~~~~~~~~

This is master, right?

bug#28596: Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news

[N. Jackson]

retitle 28596 Gnus gets into an ambiguous plugged/unplugged state that prevents retrieval of news
quit

I am re-titling the bug report, because as far as I can see, the
bug is not about retrieving mail, only news; and also I'm
increasingly convinced that the hang I was observing when I first
reported the bug was simply because while I was trying to
extricate Gnus from it's confused/broken state I failed to follow
the protocols I usually follow to prevent being bitten by Bug
16026/16906 (which causes a hang).

Also, I now have a recipe that seems to reproduce the bug reliably
here, but it is by no means a minimal recipe:

1. Turn off Internet connection.
2. Start Emacs (26.0.90 pretest)
3. Start Gnus with `gnus-unplugged'
4. Retrieve mail from my local IMAP server with `g' command (`gnus-group-get-new-news')
5. Restore connectivity to Internet
6. (Try to) put Gnus into plugged state with `J j' (`gnus-agent-toggle-plugged')

Result: Mode line now says "Plugged" instead of "Unplugged" but
nntp servers cannot be put in an Open state. Rather agentised
servers can be either Closed or Offline and unagentised servers
can be either Closed or Denied.

At 12:14 -0500 on Monday 2017-12-04, N. Jackson wrote:
> However, I had forgotten (or never saw) your suggestions to
>
>   "try setting url-asynchronous to nil when fetching news... [o]r
>   maybe even build Emacs with HAVE_GETADDRINFO_A undefined"
>
> and I will try that with 26.0.90 these next days.

Following up on this (negatively) for completeness:

1. I restarted Emacs and then set `url-asynchronous' to nil, but
no, this did not prevent Gnus from getting into the
confused/broken state.

2. I also re-built the pretest (26.0.90) with HAVE_GETADDRINFO_A
undefined, but no, that did not prevent the bug from manifesting
either.

N.