[ http://issues.apache.org/jira/browse/MODPYTHON-69?page=all ] Graham Dumpleton closed MODPYTHON-69: -------------------------------------
> 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.7 > Environment: All > Reporter: Jim Gallacher > Fix For: 3.2.7 > > 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 deadlock 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. -- 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
