[ http://issues.apache.org/jira/browse/MODPYTHON-102?page=comments#action_12364549 ]
Graham Dumpleton commented on MODPYTHON-102: -------------------------------------------- After much digging, documented at: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01062.html http://www.mail-archive.com/python-dev@httpd.apache.org/msg01064.html http://www.mail-archive.com/python-dev@httpd.apache.org/msg01065.html Problem found to be because initial read from connection could return EAGAIN but _conn_read() wasn't dealing with that case. The code needed to be checking for the bucket brigade being empty. Suggested fix to _conn_read() is to use: while (APR_BRIGADE_EMPTY(bb)) { Py_BEGIN_ALLOW_THREADS; rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize); Py_END_ALLOW_THREADS; if (! APR_STATUS_IS_SUCCESS(rc)) { PyErr_SetObject(PyExc_IOError, PyString_FromString("Connection read error")); return NULL; } } Note also that bug also found in buffer resizing code. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01050.html Specifically: if (len == 0 && bytes_read == bufsize) { _PyString_Resize(&result, bufsize + HUGE_STRING_LEN); buffer = PyString_AS_STRING((PyStringObject *) result); buffer += bufsize; bufsize += HUGE_STRING_LEN; } The "buffer" was being offset by HUGE_STRING_LEN before when it should have been bufsize (or bytes_read). > Bus error with connection handler on secondary port. > ---------------------------------------------------- > > Key: MODPYTHON-102 > URL: http://issues.apache.org/jira/browse/MODPYTHON-102 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2 > Environment: Mas OS X 10.3 (Panther) > Reporter: Graham Dumpleton > > Logging this one for posterity as hardly likely that anyone would use > connection handlers with mod_python for anything meaningful. > Basic problem is that use of connection handler on secondary listener port is > resulting in a bus error deep in Apache code when it tries to read data from > the connection. The problem initially only seems to be present on Mac OS X > 10.3. The problem could not be duplicated on Linux. On Mac OS X the problem > occurred with both Apache 2.0.51 and 2.0.55 in both prefork and worker MPM > modes. > The connection handler code that was being used was: > from mod_python import apache > def connectionhandler(conn): > apache.log_error("connectionhandler") > try: > while 1: > #conn.write(conn.readline()) > conn.write(conn.read()) > except IOError: > pass > return apache.OK > If this is enabled for the default listener port for Apache, ie., simply add > in main Apache config: > PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path' > PythonConnectionHandler example::connectionhandler > The connection handler works and is equivalent to mod_echo. > If however the connection handler is run on a secondary port, a bus error > occurs when read() or readline() is called by the connection handler. Ie., > Listen 8081 > PythonPath '["/Users/grahamd/Sites/add_handler"]+sys.path' > <VirtualHost *:8081> > PythonConnectionHandler example::connectionhandler > </VirtualHost> > Output from gdb is below. Note that if the connection handler simply returns > apache.DECLINED, everything is okay and Apache will serve up pages fine, only > when doing read of data from connection handler does it decide to crash. > (gdb) cont > Continuing. > Program received signal EXC_BAD_ACCESS, Could not access memory. > [Switching to process 2342 thread 0xc03] > 0x00000058 in ?? () > (gdb) where > #0 0x00000058 in ?? () > Cannot access memory at address 0x58 > Cannot access memory at address 0x58 > #1 0x006068f8 in _conn_read (c=0x1933014, mode=AP_MODE_READBYTES, len=0) at > connobject.c:117 > #2 0x00606b04 in conn_read (self=0x471da0, args=0xf0101140) at > connobject.c:177 > #3 0x95fa94a8 in PyEval_GetFuncDesc () > #4 0x95fa6c64 in PyEval_EvalCode () > #5 0x95fa9728 in PyEval_GetFuncDesc () > #6 0x95fa9580 in PyEval_GetFuncDesc () > #7 0x95fa6c64 in PyEval_EvalCode () > #8 0x95fa9728 in PyEval_GetFuncDesc () > #9 0x95fa9580 in PyEval_GetFuncDesc () > #10 0x95fa6c64 in PyEval_EvalCode () > #11 0x95fa7e30 in PyEval_EvalCodeEx () > #12 0x95fa97dc in PyEval_GetFuncDesc () > #13 0x95fa9580 in PyEval_GetFuncDesc () > #14 0x95fa6c64 in PyEval_EvalCode () > #15 0x95fa7e30 in PyEval_EvalCodeEx () > #16 0x95f5f354 in PyFunction_SetClosure () > #17 0x95f4a8d0 in PyObject_Call () > #18 0x95f529e8 in PyMethod_New () > #19 0x95f4a8d0 in PyObject_Call () > #20 0x95f4ab7c in PyObject_CallMethod () > #21 0x0060eab0 in python_connection (con=0x192c540) at mod_python.c:1313 > #22 0x0003fce4 in ap_run_process_connection (c=0x192c540) at connection.c:42 > #23 0x0002395c in process_socket (p=0x186e598, sock=0x507f20, > my_child_num=-267382460, > my_thread_num=0, bucket_alloc=0x192c540) at worker.c:520 > #24 0x000240bc in worker_thread (thd=0x460e30, dummy=0xf0101140) at > worker.c:834 > #25 0x9499d990 in _pthread_body () > (gdb) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
