Upgrade gitian win32 to boost-1.55. #3501

Fixes issue where all network activity just stops.

Litecoin 0.8.6.1 upgraded the gitian win32 environment to precise and boost-1.54 in exactly the same manner as Bitcoin master. After Litecoin 0.8.6.1 was released we began to hear complaints from Windows users about block sync getting stuck forever. When networking stops the GUI remains responsive and the debug.log has a few lines like this before stopping entirely.

2013-12-28 12:40:46 socket send error 10054 2013-12-28 12:40:46 disconnecting node 125.86.21.116:1985

Several hours after the point where it fails, netstat -a on Windows reports a great many connections stuck in the CLOSED_WAIT state.

https://litecointalk.org/index.php?topic=12526.0 Testing by several members of the Litecoin community found that downgrading to boost-1.50 seemed to fix the issue. We also tried boost-1.55 which also seems to fix the issue.

https://svn.boost.org/trac/boost/ticket/8933 This upstream ticket against boost-1.54 might be related. This is confusing though as Bitcoin does not use boost ASIO except for RPC which is disabled by default on the -qt builds. Whatever the issue, at this point it seems that boost-1.55 solves the issue, or at least none of the Litecoin testers of the boost-1.55 builds have reported the permanent network failure condition that occurs with boost-1.54.

http://download1.rpmfusion.org/~warren/bitcoin-win32-network-test/ This is a gitian win32 build of bitcoin-qt.exe at 13e99e463d4aa0bd2b2892010ca8c7007c40c242. I personally reproduced a similar failure only a few thousand blocks into a fresh sync on Windows 7 x64. Unlike the 0.8.x + boost-1.54 client it did not have the 10054 errors in debug.log. Instead the log just stopped. GUI remained responsive. Subsequent addnode ADDRESS onetry appeared to add an entry to getpeerinfo but it was clearly defective.

Note that it failed to read the subver and it received zero bytes from this peer.

WSAECONNRESET 10054 Connection reset by peer.

An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

From http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx

Test results of both Litecoin-0.8.x + boost-1.55 and Bitcoin master + boost-1.55 are looking quite good.

Compared the 1.55 source tarball to upstream, Arch Linux and Gentoo.

Tried building and running this. Works fine for me. But I cannot reproduce the original issue so can't comment whether it is solved.

Updated the commit message.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/56fce1fdbb688e9c48ba689d8f69bf66501d91c5 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

My own build didn't suffer from this, but I'm also using Boost 1.55 currently and have no networking problems. Can you try to also update the readme files, if they mention a concrete Boost version.

Two more testers of the boost-1.54 win32 gitian build reproduced networking failure.

http://download1.rpmfusion.org/~warren/bitcoin-win32-network-test/with-boost155/ And with this build with boost-1.55 the problem has disappeared.

@Diapolo What versions of other libraries do you test with? Perhaps we should upgrade the other gitian win32 deps to match so we don't have more surprises like this.

@wtogami BDB 4.8.30.NC Boost 1.55 OpenSSL 1.0.1e protobuf 2.5.0 Qt 5.2.0

@Diapolo Is it the plan to make qt5 default for win32 Bitcoin Core 0.9?

Let's move this onto the mailing list, this is getting off topic.

AFAIK @laanwj plans to make Qt5.x the default for 0.9 release, which I would also suggest.

For Qt5 discussion please use #3346 We're almost ready to merge there, although sipa found an issue with plain --with-qt. Not sure if it should hold up merging.