Re: mod_python 3.2.5b - FreeBSD 6.0 segfault
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 test.py, line 1220, in test_connectionhandler f = urllib.urlopen(url) File /usr/local/lib/python2.4/urllib.py, line 77, in urlopen return opener.open(url) File /usr/local/lib/python2.4/urllib.py, line 185, in open return getattr(self, name)(url) File /usr/local/lib/python2.4/urllib.py, line 317, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File /usr/local/lib/python2.4/urllib.py, line 334, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File /usr/local/lib/python2.4/urllib.py, line 574, in http_error_default return addinfourl(fp, headers, http: + url) File /usr/local/lib/python2.4/urllib.py, line 863, in __init__ addbase.__init__(self, fp) File /usr/local/lib/python2.4/urllib.py, line 813, in __init__ self.read = self.fp.read 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 0x0058 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/mod_python.so #4 0x28501699 in PyEval_EvalFrame () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #5 0x28501cec in PyEval_EvalCodeEx () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #6 0x2853b3ea in function_call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #7 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #8 0x284c7f8e in instancemethod_call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #9 0x284c254c in PyObject_Call () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #10 0x284c2721 in PyObject_CallMethod () from /home/barryp/mod_python-3.2.5b/src/mod_python.so #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 - Py_BEGIN_ALLOW_THREADS; rc = ap_get_brigade(c-input_filters, bb, mode, APR_BLOCK_READ, bufsize); Py_END_ALLOW_THREADS; --- 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. Barry
Re: mod_python 3.2.5b available for testing
OK, I think we got enough +1's and no show-stopping problems (for a beta at least). I copied it over the apache server, once the mirrors sync I'll update the site and send the big announcement. Grisha On Mon, 14 Nov 2005, Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: mod_python 3.2.5b available for testing
Gregory (Grisha) Trubetskoy wrote: OK, I think we got enough +1's and no show-stopping problems (for a beta at least). I copied it over the apache server, once the mirrors sync I'll update the site and send the big announcement. I was also thinking it was time for a wider release, but was hoping to see a +1 for FreeBSD 4 or 5 first. I've been sporadically trying to test mod_python on FreeBSD 5.4 using qemu but with no success. Not a big suprise since I can't get 3.1.4 to work either. I've likely messed something up as this was my first attempt with either FreeBSD or qemu. FreeBSD feels like a foreign country where everyone speaks English but with a funny accent. I'm sure I'll adjust. On the subject of qemu, one of my longer term projects is to setup an automated test environment using qemu images of the most popular linux and bsd distros. I get to decide what's popular. No arguments. No flamewars. ;) Qemu ain't fast, but it is effective and cheap. (To put things in context the unit tests alone take approx 10 minutes. Granted my computer is not a screamer, but still...) So far I have working images of Debian stable, Debian unstable and Gentoo, plus the afore mentioned but messed up FreeBSD. As time (and disk space) permit I'll add some combination of Fedora, maybe one of the RHEL clones, SUSE, Ubuntu or whatever else strikes my fancy. Once I cobble together some scripts to control qemu and automate the configure/make/test cycle we'll have ourselves a nice little virtual build farm. Let the computers work while we sleep, I say. If I ever get around to fully implementing this grand scheme we'll have a tool which will hopefully speed up the release cycle. Is this Friday? It sure feels like Friday. Usually I only ramble on like this on Fridays. :) Dang. It's not Friday. Back to work. Jim
[jira] Commented: (MODPYTHON-76) input filter hangs in combination with mod_proxy
[ http://issues.apache.org/jira/browse/MODPYTHON-76?page=comments#action_12357955 ] Graham Dumpleton commented on MODPYTHON-76: --- For further details on this issue see developer mailing list posts. http://article.gmane.org/gmane.comp.apache.mod-python.devel/1341/match=martijn http://article.gmane.org/gmane.comp.apache.mod-python.devel/1350/match=martijn The offending package that might be used as a test case is called Tramline, which is available from: http://faassen.n--tree.net/blog/view/weblog/2005/11/11/0 http://codespeak.net/svn/rr/tramline/trunk/ If it really is a requirement that automatic flushing needs to be able to be turned off, suggest that add a new configuration directive called PythonFlushFilter be implemented. The default if not defined would be On, with it being able to be specified as Off. But then, the mailing list posts suggest that the workaround of disabling the flush may not work for all Apache versions. input filter hangs in combination with mod_proxy Key: MODPYTHON-76 URL: http://issues.apache.org/jira/browse/MODPYTHON-76 Project: mod_python Type: Bug Components: core Versions: 3.2, 3.1.4 Environment: Linux, Apache 2.024 and unreleased Apache 2.0.x svn version. Reporter: Martijn Faassen Input filters hang when mod_proxy is in use. Other behavior seen is infinite calls of the input filter function even though the data has already been processed. In Apache 2.0.24, this problem seems to be fundamental; I have no way to get rid of the hang, except perhaps in the case of an input filter that does not change the size of the passed-through data. In svn Apache, the problem goes away as soon as I remove the filter.flush() in apache.py's FilterDispatch handler. svn Apache does according to its changelog contain a fix to mod_proxy's handling of input filters. For my application, use of mod_proxy is essential, as mod_python is essentially proxying another web server process. Output filters do not seem to be affected by the presence of filter.flush(), and in fact filter.flush() is important to make sure memory use remains small when handling large amounts of data being outputted by the server. All of this is rather hairy and I don't know quite what to blame; part of this seems indeed due to Apache itself, but perhaps not everything. -- 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
[jira] Created: (MODPYTHON-92) Raise more specific IOError when req.write() fails.
Raise more specific IOError when req.write() fails.
---
Key: MODPYTHON-92
URL: http://issues.apache.org/jira/browse/MODPYTHON-92
Project: mod_python
Type: Improvement
Components: core
Versions: 3.3
Reporter: Graham Dumpleton
Priority: Minor
Currently when req.write() fails in being able to be write back response
content due to the client side connection having been dropped, an IOError
exception is raised.
if (len 0 ) {
Py_BEGIN_ALLOW_THREADS
rc = ap_rwrite(buff, len, self-request_rec);
if (flush (rc != -1))
rc = ap_rflush(self-request_rec);
Py_END_ALLOW_THREADS
if (rc == -1) {
PyErr_SetString(PyExc_IOError, Write failed, client closed
connection.);
return NULL;
}
}
In the top level HandlerDispatch() function, when dealing with exceptions
raised by a handler it has a special case whereby it traps instances of the
IOError exception.
if str(etype) == exceptions.IOError \
and str(evalue)[:5] == Write:
# if this is an IOError while writing to client,
# it is probably better not to try to write to the cleint
# even if debug is on.
debug = 0
Specifcally, it assumes that if an IOError occurs and the first part of the
associated error value string is Write it assumes that the IOError is because
of req.write() failing.
In reality this need not actually be the case as feasibly something else
entirely different could raise an IOError exception whereby the first part of
the error value string contains the same thing. Thus it is not really a good
distinguisher.
If one was going to be rigorous, mod_python would define an exception class
which derives from IOError and raise as an exception an instance of the derived
class instead. By being a derived class, all user code which currently tried to
catch an IOError being raised from req.write() would still work, but the
HandlerDispatch() function could explicitly catch the derived class type and
thus be 100% certain that it was actually an error from req.write().
Note that in practice all that is affected by mod_python currently being too
broad in what it catches is that when PythonDebug is enabled, the details of
those exceptions wrongly caught wouldn't be displayed back to the browser. As
such, the impact is very minimal and fixing it should be regarded as being very
low priority.
--
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
