Reputation: 6286
When running a test using the Tornado AsyncHTTPTestCase I'm getting a stack trace that isn't related to the test. The test is passing so this is probably happening on the test clean up?
I'm using Python 2.7.2, Tornado 2.2.
The test code is:
class AllServersHandlerTest(AsyncHTTPTestCase):
def get_app(self):
return Application([('/rest/test/', AllServersHandler)])
def test_server_status_with_advertiser(self):
on_new_host(None, '127.0.0.1')
response = self.fetch('/rest/test/', method='GET')
result = json.loads(response.body, 'utf8').get('data')
self.assertEquals(['127.0.0.1'], result)
The test passes ok, but I get the following stack trace from the Tornado server.
OSError: [Errno 9] Bad file descriptor
INFO:root:200 POST /rest/serverStatuses (127.0.0.1) 0.00ms
DEBUG:root:error closing fd 688
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\tornado-2.2-py2.7.egg\tornado\ioloop.py", line 173, in close
os.close(fd)
OSError: [Errno 9] Bad file descriptor
Any ideas how to cleanly shutdown the test case?
Upvotes: 2
Views: 1340
Reputation: 6286
I dug around in the tornado code and found that this code is setting the all_fds to True which then causes the stack trace in io_loop.close():
def tearDown(self):
if (not IOLoop.initialized() or
self.io_loop is not IOLoop.instance()):
# Try to clean up any file descriptors left open in the ioloop.
# This avoids leaks, especially when tests are run repeatedly
# in the same process with autoreload (because curl does not
# set FD_CLOEXEC on its file descriptors)
self.io_loop.close(all_fds=True)
super(AsyncTestCase, self).tearDown()
So, overriding the tearDown() in the test class stops the stack trace.
class AllServersHandlerTest(AsyncHTTPTestCase):
def tearDown(self):
pass
def get_app(self):
return Application([('/rest/test/', AllServersHandler)])
def test_server_status_with_advertiser(self):
on_new_host(None, '127.0.0.1')
response = self.fetch('/rest/test/', method='GET')
result = json.loads(response.body, 'utf8').get('data')
self.assertEquals(['127.0.0.1'], result)
I'm not sure what damage this approach could introduce, so if someone else has a better suggestion, let me know!
Upvotes: 2