Barry Pederson wrote:

 >> > FreeBSD 6.0
 >> > Apache 2.0.55 port built WITH_THREADS=1
 >> > Python 2.4.2

ERROR: test_connectionhandler (__main__.PerRequestTestCase)
Traceback (most recent call last):
  File "", line 1220, in test_connectionhandler
    f = urllib.urlopen(url)
  File "/usr/local/lib/python2.4/", line 77, in urlopen
  File "/usr/local/lib/python2.4/", line 185, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.4/", line 317, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.4/", line 334, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/", line 574, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/local/lib/python2.4/", line 863, in __init__
    addbase.__init__(self, fp)
  File "/usr/local/lib/python2.4/", line 813, in __init__ =
AttributeError: 'NoneType' object has no attribute 'read'


Looking at my logs/error_log I see

[Mon Nov 14 23:10:23 2005] [notice] child pid 53034 exit signal Segmentation fault (11), possible coredump in /home/barryp/mod_python-3.2.5b/test

I rebuilt apache and mod_python with debugging turned on, went into gdb with "gdb /usr/local/sbin/httpd httpd.core", did a "bt", and got:

#0  0x00000058 in ?? ()
#1 0x284b5ad6 in _conn_read (c=0x8258128, mode=AP_MODE_GETLINE, len=0) at connobject.c:117 #2 0x284b5d63 in conn_readline (self=0x86b6780, args=0x819002c) at connobject.c:193 #3 0x285014fa in PyEval_EvalFrame () from /home/barryp/mod_python-3.2.5b/src/ #4 0x28501699 in PyEval_EvalFrame () from /home/barryp/mod_python-3.2.5b/src/ #5 0x28501cec in PyEval_EvalCodeEx () from /home/barryp/mod_python-3.2.5b/src/ #6 0x2853b3ea in function_call () from /home/barryp/mod_python-3.2.5b/src/ #7 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/ #8 0x284c7f8e in instancemethod_call () from /home/barryp/mod_python-3.2.5b/src/ #9 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/ #10 0x284c2721 in PyObject_CallMethod () from /home/barryp/mod_python-3.2.5b/src/
#11 0x284bea7d in python_connection (con=0x8258128) at mod_python.c:1281
#12 0x284bfbd5 in PythonConnectionHandler (con=0x8258128) at mod_python.c:1929 #13 0x08075546 in ap_run_process_connection (c=0x8258128) at connection.c:43 #14 0x08075940 in ap_process_connection (c=0x8258128, csd=0x8258050) at connection.c:176
#15 0x08068971 in child_main (child_num_arg=0) at prefork.c:610
#16 0x08068afb in make_child (s=0x80b5df8, slot=0) at prefork.c:704
#17 0x08068b71 in startup_children (number_to_start=3) at prefork.c:722
#18 0x08068f6e in ap_mpm_run (_pconf=0x80b4018, plog=0x80e0018, s=0x80b5df8) at prefork.c:941
#19 0x0806fd5e in main (argc=5, argv=0xbfbfea90) at main.c:638

I've been looking into this crash, learning a little gdb along the way, and adding some ap_log_cerror calls to the program, and have only been able to figure out that in connobject.c, around line 75

rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);

after this point, the bucket-brigade "bb" seems to contain a corrupt bucket (later on pointed to by "b"), that at the very least has its type field pointing at some garbage, instead of what I'm guessing should be apr_bucket_type_heap. b->type->read has a value of 0x58, which explains the first line of that backtrace.

I thought this might be a threading problem, and removed those "ALLOW_THREADS" macros around the ap_get_brigade call, but that didn't change the result at all.

So I guess I'm a bit stumped as to what's messing up this bucket.


Reply via email to