[mod_python] Seg Fault when using session object

Emlyn Jones emlynj at gmail.com
Sun Jun 25 20:34:53 EDT 2006

On Monday 26 Jun 2006 01:13, Graham Dumpleton wrote:
> Emlyn Jones wrote ..
> > Hello,
> > I've got this simple piece of mod_python/psp; If I uncomment the
> > foo=session line I get a seg fault. Has anyone seen this before and can
> > direct me towards finding out what the problem is please?
> > I'm running Apache/2.0.50, mod_python 3.2.8 and Python 2.4.
> > I've confirmed that it isn't the known expat and mysql/php problems.
> >
> > <%
> > #foo = session
> > done_login = False
> > if(form.has_key("username")):
> >       username = form["username"]
> >       password = form["password"]
> >       req.write("%s" % (username,))
> > %>
> What PSP does is that if it sees that the variable "session" is referenced
> from inside of PSP code, then it will do what is necessary to create the
> session, or if the session already exists, it will retrieve it from the
> session database.
> Two problems could be occurring here. The first is that if this is
> occurring on the very first time the session needs to be created, that the
> session database it tries to use is corrupt in some way and therefore
> crashing. The second is that the session already exists in the database,
> but something was stored in the session object that probably shouldn't have
> and when the session object is being restored, it is triggering some code
> (possibly C code) which is then subsequently crashing.
> First thing you need to do is get out of PSP and write a simple handler
> that creates a session object just to validate that sessions work and that
> the session database is okay. Use a handler such as:
>   from mod_python import Session
>   from mod_python import apache
>   def handler(req):
>     session = Session.Session(req)
>     session['data'] = 1
>     session.save()
>     req.content_type = 'text/plain'
>     req.write('hello')
>     return apache .OK
> If this dies, then there is possibly a problem with the session
> database, or your Python DBM modules are stuffed somehow. You need to
> work out what type of session database is being used. It will probably
> be DBM database and it will be stored in "/tmp" as "/tmp/mp_sess.dbm". I
> am guessing you aren't on Win32 as in that case an in memory session
> database is being used and it would be almost impossible to crash. Which
> is might be is dictated by the MPM which Apache was configured with.
> Assuming it is DBM, check who owns the database in "/tmp". The owner
> should match the user that Apache runs as. If you have multiple versions
> of Apache running and they run as different users, you could have problems
> because of that. If it is the wrong user and you only have one Apache
> instance, you could try deleting the database and restarting Apache.
> If you have multiple versions of Apache running as different users, you
> may have to use PythonOption to change location where session database
> is stored. See documentation for mod_python.
> If this is all okay, may be what you are storing in the session object.
> This is where you need to show your code as to what you are sticking in the
> session object before we can really comment. Also read:
>   http://www.dscpl.com.au/articles/modpython-005.html
> Graham

Hi Graham, thanks for the reply and explanation.
That simple handler does die. The dbm file in /tmp checks out ok, it's the 
correct user and I haven't actually managed to store anything in it yet. This 
is the first use of it; In fact, If I rename it (the dbm file) and restart 
apache it doesn't get recreated so I guess that leaves me with the python DBM 
I'll have a dig around and see what I can come up with. 
I do vaguely remember a caffeine fuelled evening running into problems with 
sleepycat which sounds like it might be connected (maybe library versions?). 
Is there any extra debugging info I can turn on to point me in the right 
direction? Otherwise I suppose it's trying to test out the dbm stuff in a 
python shell first and take it from there.


More information about the Mod_python mailing list