GNU bug report logs - #47637
28.0.50; getaddrinfo error 11003 (Windows 10)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47637 in the body.
You can then email your comments to 47637 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Wed, 07 Apr 2021 13:24:38 +0200

On an emacs compiled from the master branch today (commit
c1173f231d46f14f71886fa343dbc7501f064919) I can no longer connect to
elpa (or melpa).  I get "elpa.gnu.org/443 getaddrinfo error 11003".  I
haven't tried any other network access, but I would not be surprised if
it was a general problem with network access.

To reproduce from emacs -Q:
M-x toggle-debug-on-error
M-x package-install RET csv-mode RET

Debugger entered--Lisp error: (error "elpa.gnu.org/443 getaddrinfo error 11003")
  signal(error ("elpa.gnu.org/443 getaddrinfo error 11003"))
  package--with-response-buffer-1("https://elpa.gnu.org/packages/" #f(compiled-function () #<bytecode -0x87849461b1db4cc>) :file "csv-mode-1.15.tar" :async nil :error-function #f(compiled-function () #<bytecode 0x1e0000153e91>) :noerror nil)
  package-install-from-archive(#s(package-desc :name csv-mode :version (1 15) :summary "Major mode for editing comma/char separated values" :reqs ((emacs (24 1)) (cl-lib (0 5))) :kind tar :archive "gnu" :dir nil :extras ((:maintainer nil . "emacs-devel <at> gnu.org") (:authors ("\"Francis J. Wright\"" . "F.J.Wright <at> qmul.ac.uk")) (:keywords "convenience") (:url . "https://elpa.gnu.org/packages/csv-mode.html")) :signed nil))
  mapc(package-install-from-archive (#s(package-desc :name csv-mode :version (1 15) :summary "Major mode for editing comma/char separated values" :reqs ((emacs (24 1)) (cl-lib (0 5))) :kind tar :archive "gnu" :dir nil :extras ((:maintainer nil . "emacs-devel <at> gnu.org") (:authors ("\"Francis J. Wright\"" . "F.J.Wright <at> qmul.ac.uk")) (:keywords "convenience") (:url . "https://elpa.gnu.org/packages/csv-mode.html")) :signed nil)))
  package-download-transaction((#s(package-desc :name csv-mode :version (1 15) :summary "Major mode for editing comma/char separated values" :reqs ((emacs (24 1)) (cl-lib (0 5))) :kind tar :archive "gnu" :dir nil :extras ((:maintainer nil . "emacs-devel <at> gnu.org") (:authors ("\"Francis J. Wright\"" . "F.J.Wright <at> qmul.ac.uk")) (:keywords "convenience") (:url . "https://elpa.gnu.org/packages/csv-mode.html")) :signed nil)))
  package-install(csv-mode nil)
  funcall-interactively(package-install csv-mode nil)
  call-interactively(package-install record nil)
  command-execute(package-install record)
  execute-extended-command(nil "package-install" nil)
  funcall-interactively(execute-extended-command nil "package-install" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

The actual package does not matter, I get the same failure with a
random selection of both elpa and melpa packages.

This was (is) not the case in my previous build, from 2020-10-26
(commit: e7009a6dc2643125036154313924fd72c3d9847a).  In that build, I
could (and have) just upgraded all my packages without issue.

I am on a corporate network, with SSL traffic MITM-ed in a proxy, which
means that in Emacs, I usually get prompted to accept a certificate,
because Emacs doesn't recognize our corporate CA certificate.  In this
latest build, I don't get prompted, I immediately end up in the
backtrace above.

Compiling Emacs in this environment is something I do very rarely,
because it takes around an hour (with anti-malware things eating most of
the CPU time).  So I have made no effort (yet) to bisect.

In GNU Emacs 28.0.50 (build 4, x86_64-w64-mingw32)
 of 2021-04-07 built on W-OSL-00864
Repository revision: c1173f231d46f14f71886fa343dbc7501f064919
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Enterprise (v10.0.1909.18363.1441)

Configured using:
 'configure --prefix=/c/Emacs/Emacs-git --without-dbus
 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: Debugger

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-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
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs rfc822 mml
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader sendmail mail-utils cl-extra help-fns radix-tree
cl-print debug backtrace help-mode find-func gnutls network-stream
url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny url-cache url-auth cus-edit pp cus-start
cus-load wid-edit finder-inf package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 106434 5731)
 (symbols 48 10223 1)
 (strings 32 33896 1072)
 (string-bytes 1 976006)
 (vectors 16 18268)
 (vector-slots 8 225031 14952)
 (floats 8 41 327)
 (intervals 56 881 0)
 (buffers 992 12))

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

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Tue, 13 Apr 2021 19:57:51 +0200

On Wed, 2021-04-07 13:24:38 +0200, Peder O. Klingenberg wrote:

> On an emacs compiled from the master branch today (commit
> c1173f231d46f14f71886fa343dbc7501f064919) I can no longer connect to
> elpa (or melpa).  I get "elpa.gnu.org/443 getaddrinfo error 11003".  I
> haven't tried any other network access, but I would not be surprised if
> it was a general problem with network access.

Never mind, this was just a problem running src/emacs from the build
root.  Once I did "make install" and ran the installed binary, the
problem went away.

Sorry for the noise.

...Peder...

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Wed, 14 Apr 2021 10:04:13 +0200

"Peder O. Klingenberg" <peder <at> klingenberg.no> writes:

> Never mind, this was just a problem running src/emacs from the build
> root.  Once I did "make install" and ran the installed binary, the
> problem went away.

That's really odd, though -- doing a "make install" shouldn't affect
things like that.

However, you did mention running some anti-malware software on the
system -- is it possible that that's stopping network connections from
src/emacs, but not when it's installed?  (That would be really odd, too,
but ... malware software is often pretty odd.)

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

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

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Wed, 14 Apr 2021 19:44:34 +0200

On on., 2021-04-14 kl. 10.04 +0200 +0200, Lars Ingebrigtsen wrote:

> That's really odd, though -- doing a "make install" shouldn't affect
> things like that.

I agree, but Windows never ceases to disappoint.

I didn't pay attention to the output of `make install`, maybe it does
some magic relinking or something?  All I know is I got tired of
bisection never giving me a good build, so just for "fun" I rebuilt from
my known good build, and it failed.  Then I moved away the old install
directory, did make install, and it worked.  So I built from a fresh
master again, and again it failed from the build dir, but I installed it
anyway, and the problem was gone.

I don't really have time to dig deeper into it.

> However, you did mention running some anti-malware software on the
> system -- is it possible that that's stopping network connections from
> src/emacs, but not when it's installed?

It's not outside the realm of possibilities, I guess, see my first
sentence above.  But it would be the first time I have encountered that
particular problem.  I create software from scratch on this machine,
that is certainly just as unknown to the anti-malware stuff as Emacs,
and none of my programs have ever had trouble connecting to outside
network stuff.

(I do in part blame the anti-malware for the compilation being almost
unbearably slow.  Along with Windows itself.  Opening and closing files
and spawning processes are such rare things to demand of an OS, let's
aggressively pessimise those use cases!)

...Peder...
-- 
Sløv uten dop

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: larsi <at> gnus.org, 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Wed, 14 Apr 2021 21:07:39 +0300

> From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
> Date: Wed, 14 Apr 2021 19:44:34 +0200
> Cc: 47637 <at> debbugs.gnu.org
> 
> I didn't pay attention to the output of `make install`, maybe it does
> some magic relinking or something?  All I know is I got tired of
> bisection never giving me a good build, so just for "fun" I rebuilt from
> my known good build, and it failed.  Then I moved away the old install
> directory, did make install, and it worked.  So I built from a fresh
> master again, and again it failed from the build dir, but I installed it
> anyway, and the problem was gone.

It could be that you have more than one GnuTLS library installed on
your system, and the build in the source tree picks up the "wrong"
one.

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

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Wed, 14 Apr 2021 22:48:40 +0200

> On 14 Apr, 2021, at 20:07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> It could be that you have more than one GnuTLS library installed on
> your system, and the build in the source tree picks up the "wrong"
> one.

Maybe?  How can I tell which library each binary picks up?  I tried running ldd on src/emacs and the installed emacs (from the same build) and diffing the results, without seeing anything that jumped out at me (I can get at the exact ldd output tomorrow, if necessary, but I’m on a machine without access to the corporate VPN at the moment).

…Peder...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: larsi <at> gnus.org, 47637 <at> debbugs.gnu.org
Subject: Re: bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)
Date: Thu, 15 Apr 2021 09:10:43 +0300

> From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
> Date: Wed, 14 Apr 2021 22:48:40 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
>  47637 <at> debbugs.gnu.org
> 
> 
> > On 14 Apr, 2021, at 20:07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> > It could be that you have more than one GnuTLS library installed on
> > your system, and the build in the source tree picks up the "wrong"
> > one.
> 
> Maybe?  How can I tell which library each binary picks up?

I use Process Explorer from SysInternals suite.  There's also ListDLLs
from the same suite.

Previous Next

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