[ 
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

Reply via email to