Ticket #317 (defect)
Opened 3 years ago
Last modified 3 years ago
crash in testMaxRequestSize on Mac OS X
Status: closed (fixed)
| Reported by: | speno | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1-rc2 |
| Component: | CherryPy code | Keywords: | crash macosx httperrors |
| Cc: |
There's a Mac OS X bug with Python (or maybe the OS) that causes problems with sockets.
http://sourceforge.net/tracker/index.php?func=detail&aid=1092502&group_id=5470&atid=105470
I'm not sure, but I believe this bug is causing testMaxRequestSize to fail. A 'bus error' and core dump is caused by this code in test/test_core.py
#!python
if cherrypy._httpserver.__class__.__name__ == "WSGIServer":
cherrypy.config.update({
'/maxrequestsize': {'server.maxRequestBodySize': 3}})
self.getPage('/maxrequestsize/upload', h, "POST", b)
self.assertStatus("413 Request Entity Too Large")
self.assertInBody("Request Entity Too Large")
Change History
09/24/05 09:21:19: Modified by speno
- severity changed from normal to critical.
- milestone set to 2.1-rc2.
09/26/05 14:27:26: Modified by speno
- description changed.
I'm not sure it's the socket bug that is causing this. For one thing, I'm not getting a MemoryError? which is indicative of that problem. For another, I traced the crash way down to this line in _cputil.py:
return "".join(traceback.format_exception(*exc))
And here's a pdb stack trace that might help:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py(442)__bootstrap() -> self.run() /private/tmp/cherrypy/_cpwsgiserver.py(252)run() -> for line in response: /private/tmp/cherrypy/_cpwsgi.py(111)wsgiApp() -> environ['wsgi.url_scheme'], /private/tmp/cherrypy/server.py(218)request() -> requestLine, headers, rfile, scheme) /private/tmp/cherrypy/_cphttptools.py(210)__init__() -> self.run() /private/tmp/cherrypy/_cphttptools.py(286)run() -> inst.set_response() /private/tmp/cherrypy/_cperror.py(195)set_response() -> statusString, defaultBody = cherrypy._cputil.getErrorStatusAndPage(self.status) /private/tmp/cherrypy/_cputil.py(196)getErrorStatusAndPage() -> traceback = formatExc() /private/tmp/cherrypy/_cputil.py(211)formatExc() -> return "".join(traceback.format_exception(*exc)) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(145)format_exception() -> list = list + format_exception_only(etype, value) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(190)format_exception_only() -> s = _some_str(value) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(199)_some_str() -> return str(value) /private/tmp/cherrypy/_cperror.py(222)__str__() -> return cherrypy._cputil.getErrorStatusAndPage(self.status)[0] /private/tmp/cherrypy/_cputil.py(196)getErrorStatusAndPage() -> traceback = formatExc() /private/tmp/cherrypy/_cputil.py(211)formatExc() -> return "".join(traceback.format_exception(*exc)) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(145)format_exception() -> list = list + format_exception_only(etype, value) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(190)format_exception_only() -> s = _some_str(value) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/traceback.py(199)_some_str() -> return str(value) /private/tmp/cherrypy/_cperror.py(222)__str__() -> return cherrypy._cputil.getErrorStatusAndPage(self.status)[0] /private/tmp/cherrypy/_cputil.py(196)getErrorStatusAndPage() -> traceback = formatExc() > /private/tmp/cherrypy/_cputil.py(211)formatExc() -> return "".join(traceback.format_exception(*exc))
I don't have the stamina to keep working on this just now. Well, maybe one more thing...
09/26/05 15:20:36: Modified by speno
- keywords changed from crash macosx to crash macosx httperrors.
I'm pretty sure the bug is in _cperror.HTTPError's str method. It's looping back there from python's traceback module line 199.
09/26/05 15:31:09: Modified by fumanchu
There may be a bug in the __str__ method, but if so it's probably due to the traceback code, not the test suite itself. That is, when I intentionally break __str__, the test suite still passes, so I don't think it's called in normal circumstances.
09/26/05 17:52:43: Modified by speno
Well, I see it being called in Solaris even when the tests claim to be passing.
On Mac OS X, python crashes after about 108 calls to format_traceback. Solaris got more calls, but didn't crash.
09/27/05 09:59:15: Modified by speno
- status changed from new to closed.
- resolution set to fixed.
This wasn't a Mac OS X socket problem. It was a bug fixed by fumanchu in changeset [682] with the candlestick.
If testMaxRequestSize is disabled, the test still crash, just a bit later:
test_Ranges (test_core.CoreRequestHandlingTest?) ... Bus error
All other tests pass.
These are pretty serious problems, IMO.