| Nicolas Lehuen (JIRA) 2005-08-10, 7:46 am |
| [ http://issues.apache.org/jira/brows...HON-69?page=all ]
Nicolas Lehuen resolved MODPYTHON-69:
-------------------------------------
Fix Version: 3.2.0
Resolution: Fixed
> Potential deadlock in psp cache
> -------------------------------
>
> Key: MODPYTHON-69
> URL: http://issues.apache.org/jira/browse/MODPYTHON-69
> Project: mod_python
> Type: Bug
> Components: publisher
> Versions: 3.2.0
> Environment: All
> Reporter: Jim Gallacher
> Fix For: 3.2.0
>
> This issue was discussed on the python-dev mailing list but not followed up on. Fixing that now.
> In psp.py
> def dbm_cache_store(srv, dbmfile, filename, mtime, val):
> dbm_type = dbm_cache_type(dbmfile)
> ### potential deadlock here! ###
> _apache._global_lock(srv, "pspcache")
> try:
> dbm = dbm_type.open(dbmfile, 'c')
> dbm[filename] = "%d %s" % (mtime, code2str(val))
> finally:
> try: dbm.close()
> except: pass
> _apache._global_unlock(srv, "pspcache")
> "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 chance for a hash collision if a session is used in the same request, which would result in a deadlock. (This has been confirmed by testing.)
> Most obvious solution is to use the global lock 0, which will serialize all accesses to either pspcache.dbm. Global lock 0 is also used by DbmSession, but since the lock is not held for the duration of the request there should not be any additional dead
lock issues.
> The fix is to replace the _apache._global_lock(srv, "pspcache") with
> _apache._global_lock(srv, None, 0)
> The corresponding lock handling in dbm_cache_get() will also need the same fix.
> I will commit the this fix shortly.
|