Failure recovering connection on Windows

Question

Failure recovering connection on Windows

3noch opened this issue 10 years ago · comments

Moved from haskell/cabal#2035.

Most pertinent: compiling and running this program with GHC 7.8.3 produces the following on my Windows 8.1 x64 machine. I have tried to reproduce on VMs but can't.

http-test> ghc --make Main.hs -o test.exe -prof -auto-all -caf-all
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking test.exe ...

http-test> .\test.exe +RTS -xc
Trying to download http://hackage.haskell.org/packages/archive/00-index.tar.gz
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.18.0.5


Creating new connection to hackage.haskell.org
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
Received:
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.0
Date: Mon, 18 Aug 2014 22:29:21 GMT
Content-Type: text/plain; charset=UTF-8
Connection: keep-alive
Location: /packages/index.tar.gz
Content-Length: 0


301 - redirect
Redirecting to http://hackage.haskell.org/packages/index.tar.gz ...
Sending:
GET /packages/index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.18.0.5


Recovering connection to hackage.haskell.org
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
  Main.main,
  called from :Main.CAF:main
test.exe: <socket: 336>: hGetBufSome: failed (Unknown error)

Ganesh Sittampalam · Answer 1 · Wed Aug 27 2014 02:41:12 GMT+0800 (China Standard Time)

Could you check if this is a regression between 4000.2.16 and 4000.2.17? It turns out #68 is a regression caused by 5c1c7ba, though we don't yet know the details. As this problem is in vaguely the same area it seems worth checking.

Elliot Cameron · Answer 2 · Wed Aug 27 2014 03:32:04 GMT+0800 (China Standard Time)

@hsenag Sure, I'll check.

Elliot Cameron · Answer 3 · Tue Sep 02 2014 00:03:10 GMT+0800 (China Standard Time)

@hsenag Still no luck.

http-test> dist\build\http-test\http-test.exe
Trying to download http://hackage.haskell.org/packages/archive/00-index.tar.gz
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.18.0.5


Creating new connection to hackage.haskell.org
Received:
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.0
Date: Mon, 01 Sep 2014 16:00:40 GMT
Content-Type: text/plain; charset=UTF-8
Connection: keep-alive
Location: /packages/index.tar.gz
Content-Length: 0


301 - redirect
Redirecting to http://hackage.haskell.org/packages/index.tar.gz ...
Sending:
GET /packages/index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.18.0.5


Recovering connection to hackage.haskell.org
http-test.exe: <socket: 336>: hGetBufSome: failed (Unknown error)

Here's what was linked (notice some interesting warnings):

http-test> cabal repl
Preprocessing executable 'http-test' for http-test-0.1.0.0...
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package Win32-2.3.0.2 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package text-1.1.0.0 ... linking ... done.
Loading package hashable-1.2.2.0 ... linking ... done.
Loading package case-insensitive-1.1.0.3 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.3.1 ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package network-2.4.2.3 ... linking ... ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa
ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo
ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo
ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo
ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
done.
Loading package old-time-1.1.0.2 ... linking ... done.
Loading package HTTP-4000.2.16 ... linking ... done.
Ok, modules loaded: Main.

Elliot Cameron · Answer 4 · Thu Oct 02 2014 06:31:37 GMT+0800 (China Standard Time)

Anyway I can help further to track this bug down?

Ganesh Sittampalam · Answer 5 · Fri Oct 03 2014 14:12:27 GMT+0800 (China Standard Time)

It's going to be hard unless we can isolate what is triggering it on your system.

I've recently got a new Windows 8.1 machine and I've tried your test program myself with GHC 7.8.3, both 32 bit and 64 bit versions, and it works fine. I don't get any of the ws2_32 warnings above.

Note that I do have msys2 installed, but I've also tried compiling and running directly from a command prompt.

Some random thoughts:

Are gcc and ld coming from the right place (i.e. mingw/bin in the GHC install)?
Does GHC 7.6.3 work?
Are you using 32-bit or 64-bit GHC and have you tried the other one?
Is the problem with the build binary or your machine, i.e. if you move a binary from your machine to a working one does the binary work, and vice-versa?

I also googled for your warning and found
https://ghc.haskell.org/trac/ghc/ticket/8918 and haskell/network#132

I'm not sure if they are relevant but it may be worth trying a recent version of the network package from github.

Elliot Cameron · Answer 6 · Sun Oct 05 2014 00:25:58 GMT+0800 (China Standard Time)

Terrible news: I can no longer reproduce this! My only guess as to why it disappeared is some combination of the following:

Installing Cygwin (although removing it has not reintroduced the issue)
Windows update of some sort
Update to Covenant Eyes (Internet monitoring/filtering software)

My money is on the last one.

Ganesh Sittampalam · Answer 7 · Sun Oct 05 2014 15:02:30 GMT+0800 (China Standard Time)

Well, at least your problem is fixed :-) Hopefully the record will be useful if anyone else has a random problem like this in future.

Adam Sapek · Answer 8 · Mon Dec 08 2014 15:29:47 GMT+0800 (China Standard Time)

I can reproduce the problem on my Windows Server 2012, both with cabal update and the test program. I built the test program against http 4000.2.10 (the version in Haskell Platform 2014.2.0.0).

The problem is intermittent, it doesn't fail every time. Sometimes the test program will succeed several times in a row and sometimes it will fail several times in a row.

Ganesh Sittampalam · Answer 9 · Mon Dec 08 2014 15:55:09 GMT+0800 (China Standard Time)

Do you have any of the warnings the original reporter had from 'cabal repl'?

ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo

Adam Sapek · Answer 10 · Tue Dec 09 2014 04:32:27 GMT+0800 (China Standard Time)

Yes, I do see the same warnings.

Adam Sapek · Answer 11 · Fri Jan 09 2015 02:44:56 GMT+0800 (China Standard Time)

I think I know what the problem is. I'm getting the problem when running cabal behind a proxy. It seems like on my network the firewall allows outgoing connections w/o proxy but then kills them. On my network cabal also fails on Linux. The workaround that works both for Linux and Windows is to specify proxy via the environment variables HTTP_PROXY and HTTPS_PROXY.

I'm guessing that the HTTP library can no longer detect system proxy configuration on Windows 8.x. It appears to detect it on older versions of Windows.

Elliot Cameron · Answer 12 · Fri Jan 09 2015 03:04:36 GMT+0800 (China Standard Time)

Could the linking warnings be related to the inability to detect the system proxy configuration? (Good find, by the way.)

Adam Sapek · Answer 13 · Fri Jan 09 2015 03:14:52 GMT+0800 (China Standard Time)

The build warning? I doubt that, proxy detection should be a runtime operation.

Elliot Cameron · Answer 14 · Fri Jan 09 2015 04:34:16 GMT+0800 (China Standard Time)

Right, but I'm thinking that potentially linking the wrong functions at compile time could cause runtime failure.