Calling start_response() second time which exc_info can cause a crash.

[GoogleCodeExporter]

The WSGI specification allows one to do:

  try:
    # regular application code here
    status = "200 Froody"
    response_headers = [("content-type","text/plain")]
    start_response(status, response_headers)
    return ["normal body goes here"]
  except:
    # XXX should trap runtime issues like MemoryError, KeyboardInterrupt
    #     in a separate handler before this bare 'except:'...
    status = "500 Oops"
    response_headers = [("content-type","text/plain")]
    start_response(status, response_headers, sys.exc_info())
    return ["error body goes here"]

That is, try and replace the response headers with an alternate set. If no
content has been sent yet then the header replacement should succeed. If
content has already been sent, then the exc_info should instead be raised
and presumably the response will be cut off, with details of exception
being logged in some way.

In the latter case where content has already been sent, mod_wsgi will
currently crash the process at some point as it is forgetting to increment
the reference counts on exc_info components before restoring it as the
current exception state.

This paradigm isn't something that is common in WSGI applications and
especially if using a high level framework which isn't designed for WSGI
but just uses it as a hosting mechanism, you shouldn't encounter the problem. 

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 6 Oct 2007 at 12:43

[GoogleCodeExporter]

Fixed at revision 566 in 1.X branch of subversion repository:

  http://modwsgi.googlecode.com/svn/branches/mod_wsgi-1.X

Original comment by Graham.Dumpleton@gmail.com on 6 Oct 2007 at 3:15

• Changed state: Started

[GoogleCodeExporter]

Whoops. That is revision 569, not 566.

Original comment by Graham.Dumpleton@gmail.com on 6 Oct 2007 at 3:42

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 30 Oct 2007 at 2:07

• Changed state: Fixed