Short story:
I think the current CI failure in 5.5 is fixed by
https://codereview.qt-project.org/107701
Long story:
tst_qnetworkdiskcache has been trying to fetch pages from "www.foo.com", which
is a real domain. It's possible that that the infrastructure for this domain
changed recently, causing timeouts for us.
In the future, please be very careful about domain names, IP addresses, and
port numbers in unit tests. If you're reviewing code from others, please try
to validate the assumption with an eye towards the future.
Things you should avoid:
- hardcoded host names that we can't control
Example:
some unit tests tried to connect to "foo" port 80, which was fine in
Trolltech but promptly started failing once we ran tests in the Nokia
network. Similarly to www.foo.com now
Solution:
use invalid.test.qt-project.org" or localhost with a bad port number if
you'll try to connect; "example.com" is fine if your code will never
connect
- hardcoded IP addresses
Example:
When APNIC tried to delegate the 1.1.1.0/24 network to a real customer,
they discovered a huge amount of traffic due to people using "1.1.1.1"
as a
test address. For that reason, the 1.1.1.0/24 and 1.2.3.0/24 networks
are
blackholes (bogon)
Solution:
Use the IP addresses reserved by RFC 1166/5737, like 192.0.2.1
- hardcoded port numbers (including default numbers)
Example:
One of our tests tried to bind to port 1234, assuming it would never be
in use. Of course, there was a situation in which it was in use. Most
likely, it's a previous run of the test that failed to exit properly,
so
the port was still lingering open by the OS.
Solution:
If you're going to open a socket, always use port number 0, which will
ask the OS assign an unused port to you (use QTcpServer::serverPort() or
QUdpSocket::localPort() to get it).
If you're going to connect and expect it to fail, choose a very low
port
number, like 4, which is unassigned.
- connecting to outside the test network
Example:
Trying to connect to qt-project.org and check the result of those
pages.
Not only can the content change unpredictably, corporate firewalls may
block the access.
Solution:
Either use a mini HTTP server bound to localhost or use the network
test
server.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
