bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Peder O. Klingenberg
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 . "[hidden email]") (:authors ("\"Francis J. Wright\"" . "[hidden email]")) (: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 . "[hidden email]") (:authors ("\"Francis J. Wright\"" . "[hidden email]")) (: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 . "[hidden email]") (:authors ("\"Francis J. Wright\"" . "[hidden email]")) (: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))



Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Peder O. Klingenberg
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...



Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Lars Ingebrigtsen
"Peder O. Klingenberg" <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Peder O. Klingenberg
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



Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Eli Zaretskii
> From: "Peder O. Klingenberg" <[hidden email]>
> Date: Wed, 14 Apr 2021 19:44:34 +0200
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#47637: 28.0.50; getaddrinfo error 11003 (Windows 10)

Peder O. Klingenberg

> On 14 Apr, 2021, at 20:07, Eli Zaretskii <[hidden email]> 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...