Opened 16 years ago

Closed 16 years ago

Last modified 15 years ago

#9582 closed (invalid)

Unhandled exception in runserver (when losing network file?)

Reported by: Matt Labbe Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Keywords: exception runserver
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I suspect it is caused by losing network connection to the file to serve.

Trace:

Unhandled exception in thread started by <function inner_run at 0x7fb88ed4>
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/django/core/management/commands/runserver.py", line 61, in inner_run
    run(addr, int(port), handler)
  File "/usr/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 665, in run
    httpd.serve_forever()
  File "/tmp/python.6884/usr/lib/python2.5/SocketServer.py", line 201, in serve_forever
  File "/tmp/python.6884/usr/lib/python2.5/SocketServer.py", line 218, in handle_request
AttributeError: 'NoneType' object has no attribute 'error'

Change History (2)

comment:1 by Karen Tracey, 16 years ago

Resolution: invalid
Status: newclosed

I think you'd need to do more than lose network connectivity to cause this. The code from SocketServer.py that is running into trouble is:

    def handle_request(self):
        """Handle one request, possibly blocking."""
        try:
            request, client_address = self.get_request()
        except socket.error:
            return

It's the except socket.error that has raised the AttributeError, but socket was imported earlier via import socket so it's a bit odd for it to now be None. In fact it looks likes this Python issue: http://bugs.python.org/issue1731 A fix for that has been put into Python 2.5, from the timing it looks like you need 2.5.2 to have it so I suspect you are running 2.5.1?

I don't know that there's much useful we could do to 'fix' this in the dev server. Apparently the world is coming to an end and things are not necessarily being cleaned up in the right order, resulting in a spurious traceback. Even if we tried to do something (what?) it isn't clear any of our code would behave any better than the SocketServer code given the state things have gotten into.

Reopen if you've got a recreatable scenario where this happens, and some evidence that it's not in fact due to that Python issue...and indicate what you think would be better to do that what currently happens?

comment:2 by Matt Labbe, 15 years ago

I am indeed running 2.5.1.

Note: See TracTickets for help on using tickets.
Back to Top