quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Closed: (MODPYTHON-31) mod_python - session stopped working after infinite loop was killed
Date Sun, 05 Mar 2006 03:56:02 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-31?page=all ]
     
Graham Dumpleton closed MODPYTHON-31:
-------------------------------------


> mod_python - session stopped working after infinite loop was killed
> -------------------------------------------------------------------
>
>          Key: MODPYTHON-31
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-31
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.1.3
>  Environment: Using Fedora Core 3.
> --
> # rpm -q httpd
> httpd-2.0.52-3.1
> --
> --
> # rpm -q mod_python
> mod_python-3.1.3-5.2
> --
>     Reporter: Jarkko
>     Priority: Blocker

>
> /etc/httpd/conf.d/python.conf
> --
> # Add .psp to types
> AddType application/x-httpd-psp .psp
> # Handle .psp documents with mod_python
> AddHandler mod_python .psp
> PythonHandler mod_python.psp
> # Add index.psp to index documents
> DirectoryIndex index.psp
> # Enable debug under /psp directory
> <Directory /var/www/html/psp>
> AddHandler mod_python .psp_
> PythonDebug On
> </Directory>
> --
> /var/www/html/psp/index.psp
> --
> <html>
> sid: <%=session.id()%>
> </html>
> --
> lynx localhost/psp
> --
> Mod_python error: "PythonHandler mod_python.psp"
> Traceback (most recent call last):
>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 299, in 
> HandlerDispatch
>     result = object(req)
>   File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 297, in 
> handler
>     p.run()
>   File "/usr/lib/python2.3/site-packages/mod_python/psp.py", line 191, in run
>     session = Session.Session(req)
>   File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 389, in 
> Session
>     timeout=timeout, lock=lock)
>   File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 294, in 
> __init__
>     timeout=timeout, lock=lock)
>   File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 132, in 
> __init__
>     Cookie.add_cookie(self._req, self.make_cookie())
>   File "/usr/lib/python2.3/site-packages/mod_python/Session.py", line 160, in 
> make_cookie
>     c.path = dirpath[len(docroot):]
> TypeError: unsubscriptable object
> --
> First the page worked like a charm. But then I figured I'd like to see how 
> mod_python handles a situation where the page has an infinite loop in it.
> I coded a page with a code like "while True:" etc. in it and ran it. (The code 
> had a call to session too, so session was initialized.) I noticed that the 
> script was newer killed (this is bad, PHP handles this with its time limit). I 
> had to restart httpd then (which killed the script).
> Now after that loop test the session variable does not work anymore. I get 
> that "unsubscriptable object" error message.
> I figured that maybe the session data is corrupted and deleted the dbm file 
> from /tmp. That did not help. I've also restarted httpd multiple times.
> The weirdest thing about this is that the httpd is preforked, so the session 
> should exists only in memory. If the session exists only in memory, restarting 
> httpd should be enough.
> Where can that corrupted session data be stored now? Does httpd save its state 
> into some files? Even rebooting the whole machine did not help.
> I consider this bug a very serious thing because this is a blocker. Sessions 
> don't work anymore.
> Also, some kind of handling for infinite loops should be implemented. Yes I 
> know, that should be described in another bug report, but let's fix this 
> session thing first.
> I have high hopes for mod_python as it integrates an excellent language to an 
> excellent web server and because it enables a powerfull and easy alternative to 
> PHP.

-- 
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


Mime
View raw message