Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validateblocktemplate failing due PR 455 in 'dev' #518

Closed
sickpig opened this issue May 5, 2017 · 3 comments
Closed

validateblocktemplate failing due PR 455 in 'dev' #518

sickpig opened this issue May 5, 2017 · 3 comments

Comments

@sickpig
Copy link
Collaborator

sickpig commented May 5, 2017

All failure of the latest bunch of PRs (at least from #509 and up) is due to timeout on validateblockteplate.py, see: https://travis-ci.org/BitcoinUnlimited/BitcoinUnlimited/jobs/228881035#L3499

It seems that the failure is due to PR 455. Testing dev with such PR reverted fix the problem.

Basically nodes 0 is banning another peer due to unrequested block, see:

2014-01-01 11:20:00 Acceptable block: ver:20000000 time:1388568600 size: 192 Tx:1 Sig:1
2014-01-01 11:20:00 Misbehaving: 127.0.0.1:33120 (0 -> 100) BAN THRESHOLD EXCEEDED
2014-01-01 11:20:00 ERROR: Block 6ea18a333548c9ea1bd17544a9887ef66f95a874732dfb157ca0164cf915a414 was never requested, banning peer=2
2014-01-01 11:20:00 ProcessMessages(block, 192 bytes) FAILED peer=2
2014-01-01 11:20:00 Warning: not banning local peer 127.0.0.1:33120!
2014-01-01 12:20:00 Banning 127.0.0.1:33138 for 4 hours: Too many connection attempts - connection dropped

paging @ptschip

@sickpig sickpig changed the title validateblockteplate failing due PR 455 in dev validateblocktemplate failing due PR 455 in dev May 5, 2017
@sickpig sickpig changed the title validateblocktemplate failing due PR 455 in dev validateblocktemplate failing due PR 455 in 'dev' May 5, 2017
@sickpig
Copy link
Collaborator Author

sickpig commented May 5, 2017

Also adding -whitelist=127.0.0.1 to the test fix the problem. But I wonder if this is a proper things to do cause it impleis that we would have different ban policy for local node (the one running on localhost) and all the rest. (thanks to @ftrader for this finding)

@ftrader
Copy link
Collaborator

ftrader commented May 6, 2017

This test seems to work mostly now on dev HEAD (9d85241).
I've done 9 successful iterations on Debian 7 x86_64 native, and on the 10th it crashed with exotic timeout error:

[200, 200, 200, 200]
Unexpected exception caught during testing: timeout('timed out',)
  File "/home/ftrader/bu/qa/rpc-tests/test_framework/test_framework.py", line 184, in main
    self.run_test()
  File "/home/ftrader/bu/qa/rpc-tests/validateblocktemplate.py", line 65, in run_test
    self.nodes[0].generate(1001)
  File "/home/ftrader/bu/qa/rpc-tests/test_framework/coverage.py", line 49, in __call__
    return_val = self.auth_service_proxy_instance.__call__(*args, **kwargs)
  File "/home/ftrader/bu/qa/rpc-tests/test_framework/authproxy.py", line 163, in __call__
    response = self._request('POST', self.__url.path, postdata.encode('utf-8'))
  File "/home/ftrader/bu/qa/rpc-tests/test_framework/authproxy.py", line 137, in _request
    return self._get_response()
  File "/home/ftrader/bu/qa/rpc-tests/test_framework/authproxy.py", line 178, in _get_response
    http_response = self.__conn.getresponse()
  File "/home/ftrader/lib/python3.5/http/client.py", line 1197, in getresponse
    response.begin()
  File "/home/ftrader/lib/python3.5/http/client.py", line 297, in begin
    version, status, reason = self._read_status()
  File "/home/ftrader/lib/python3.5/http/client.py", line 258, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/home/ftrader/lib/python3.5/socket.py", line 575, in readinto
    return self._sock.recv_into(b)
Stopping nodes
Cannot send request: Request-sent
Cleaning up
Failed
Command '/home/ftrader/bu/qa/rpc-tests/validateblocktemplate.py --srcdir /home/ftrader/bu/src  ' returned non-zero exit status 1
Duration: 145 s

The machine was under some load at the time, so I'll re-run more iterations under less load to see if it's a sensitivity in the test / test framework.

On Ubuntu 16.10 x86_64 VM, it passed 10 times in a row.

@sickpig
Copy link
Collaborator Author

sickpig commented May 7, 2017

20 successful tests in a row dev @ 9d85241

closing

@sickpig sickpig closed this as completed May 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants