[jira] Resolved: (MODPYTHON-155) req.add_handler() and inheritance of directory to be searched for module
[ http://issues.apache.org/jira/browse/MODPYTHON-155?page=all ] Graham Dumpleton resolved MODPYTHON-155. Resolution: Fixed Memory inefficiency fixed, but more importantly new problem caused by fixes for memory leaks described in MODPYTHON-181 also addressed. req.add_handler() and inheritance of directory to be searched for module Key: MODPYTHON-155 URL: http://issues.apache.org/jira/browse/MODPYTHON-155 Project: mod_python Issue Type: Sub-task Components: importer Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 The documentation for req.add_handler() says: Optional dir is a string containing the name of the directory to be added to the pythonpath. If no directory is specified, then, if there is already a handler of the same type specified, its directory is inherited, otherwise the directory of the presently executing handler is used. I there is a PythonPath directive in effect, then sys.path will be set exactly according to it (no directories added, the dir argument is ignored). This comment about the directory being inherited from the prior or currently executing handler is actually bogus as the code does not do anything specific at all to try and implement such behaviour. If it works this way at all it is partly by luck as what will actually dictate where the module specified to the req.add_handler() method is found is the current order of directories specified in sys.path. Since additional directories added into sys.path by the old importer can be performed in effectively random order, behaviour could actually be quite random if the same module name were used in multiple directories. Because the new importer doesn't add directories into sys.path for Python*Handler directives, a problem will currently arise if no directory is supplied to req.add_handler(). Specifically, a module may not be able to be found. This is because it can no longer fall back on to fact that with old module importer, the directory corresponding to the Python*Handler directive would be listed in sys.path somewhere. Thus, the documented behaviour for req.add_handler() when the directory hasn't been set needs to actually be implemented as described with an appropriate directory being calculated at the time that req.add_handler() is called with that directory being recorded as needing to be searched for the module. In changing the code though, if old and new importers are going to be supported during a transition phase, it must detect when the new module importer is being used and only do this when it is, as otherwise it will screw up how modules are found for the old importer. -- 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] Commented: (MODPYTHON-181) Memory leak when using handlers in multiple phases at same time.
[
http://issues.apache.org/jira/browse/MODPYTHON-181?page=comments#action_12425493
]
Graham Dumpleton commented on MODPYTHON-181:
Note that you will not actually see this change in the trunk now as changes
related to MODPYTHON-155 have eliminated it, with the same handler list object
now being kept for the whole life of the request and simply reused.
Memory leak when using handlers in multiple phases at same time.
Key: MODPYTHON-181
URL: http://issues.apache.org/jira/browse/MODPYTHON-181
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.1.4, 3.3, 3.2.8
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Fix For: 3.3
When using handlers against multiple phases, ie.,
# .htaccess
PythonFixupHandler handlers
AddHandler mod_python .py
PythonHandler handlers
# handlers.py
from mod_python import apache
def handler(req):
req.content_type = 'text/plain'
req.write('handler')
return apache.OK
def fixuphandler(req):
return apache.OK
mod_python will leak memory on each request, which Apache child process sizes
blowing out quite quickly.
The problem code is in python_handler() in 'src/mod_python.c'. Specifically
the code does:
if (!hle) {
/* create a handler list object from dynamically registered handlers
*/
request_obj-hlo = (hlistobject *)MpHList_FromHLEntry(dynhle, 1);
}
else {
/* create a handler list object */
request_obj-hlo = (hlistobject *)MpHList_FromHLEntry(hle, 1);
/* add dynamically registered handlers, if any */
if (dynhle) {
MpHList_Append(request_obj-hlo, dynhle);
}
}
Problem is that request_obj-hlo can already be set by a prior phase's
handler and by simply assigning to request_obj-hlo you get a memory leak as
it refers to an existing Python object and it isn't being decref'd.
Thus, before this 'if' statement, it would appear that the following should
be inserted.
if (request_obj-hlo)
Py_DECREF(request_obj-hlo);
or:
Py_XDECREF(request_obj-hlo);
--
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
Re: mod_python 3.2.10 core vote
The site's been update (both mopython.org and the download page), so 3.2.10 is out. I'll work on the announcement next. Grisha On Mon, 31 Jul 2006, Gregory (Grisha) Trubetskoy wrote: Core +1 from me. I will take care of the signing, etc, some time tomorrow. P.S. In order for you to be able to sign you need to meet in person someone (or probably more than one person) from ASF. ApacheCon is the best place, and members do not have to pay the conference fee (at least I think that it is still true) ;-) Grisha On Thu, 27 Jul 2006, Nicolas Lehuen wrote: Just to make sure I've reinstalled my Python 2.3 test environment... So even if I've already voted, I've got an additional +1 Windows 2000 Server SP4, Apache 2.0.58 (mpm-winnt), Python 2.3.5 Regards, Nicolas 2006/7/26, Nicolas Lehuen [EMAIL PROTECTED]: +1 too. 2006/7/26, Jim Gallacher [EMAIL PROTECTED]: I think it's time for a core vote on the 3.2.10 release, as no more test results have appeared since Saturday. This vote is for the mod_python core only (Jim, Graham, Grisha and Nicolas). I am: +1 release now Jim Test summary: +1 Fedora Core 5, Apache 2.2.0 (mpm-prefork), Python 2.4.3 +1 FreeBSD 6.1-RELEASE-p2 (i386), Apache 2.2.2(mpm-prefork), python-2.4.3 +1 Gentoo 2006.0 (x86_64), Apache 2.2.2 (mpm-prefork), python-2.4.3 +1 Linux Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4.1 +1 Linux Debian Sid, Apache 2.0.55 (mpm-prefork), Python 2.3.5 +1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2 +1 Linux Ubuntu 6.06 Dapper Drake, Apache 2.0.55 (mpm-worker), Python 2.4.3 +1 MacOSX 10.4.7 Intel, Apache 2.0.55 (mpm-prefork), Python 2.4.3 +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-prefork), Python 2.3.5 +1 MacOSX 10.4.7 PPC, Apache 2.2.1 (mpm-worker), Python 2.3.5 +1 Windows XP SP2, Apache 2.0.58 (mpm-winnt), Python 2.4.3
