These tests are racy (yet another occurrence of running a TCP server and client in the same process (different threads)).
Out of the ~800 http tests, those two ones are the simplest: they connect to an http server that always reply with a 'Bad status' message and close the connection.
Running 'bzr selftest --parallel=fork -v -s bt.test_http.TestBadStatusServer' repeatedly, I can:
- see the test pass,
- see the test fail as reported,
- see the test hang
Definitely a race :-/
This can be fixed in two ways:
- run the server in a separate process,
- identify the race more precisely and fix it.
The former requires some tedious work, the later requires some deep investigation :-/
I've sent a patch to debian to disable these tests until they are properly fixed. We don't lose significant coverage doing so (pqm will still run them to gate lp:bzr).
Sorry for the reply delay :-/
I've been able to reproduce on vivid.
These tests are racy (yet another occurrence of running a TCP server and client in the same process (different threads)).
Out of the ~800 http tests, those two ones are the simplest: they connect to an http server that always reply with a 'Bad status' message and close the connection.
Running 'bzr selftest --parallel=fork -v -s bt.test_ http.TestBadSta tusServer' repeatedly, I can:
- see the test pass,
- see the test fail as reported,
- see the test hang
Definitely a race :-/
This can be fixed in two ways:
- run the server in a separate process,
- identify the race more precisely and fix it.
The former requires some tedious work, the later requires some deep investigation :-/
I've sent a patch to debian to disable these tests until they are properly fixed. We don't lose significant coverage doing so (pqm will still run them to gate lp:bzr).