Hi Nicolas,
I've been working on the elusive request.get_session() session handling
mechanism and was trying to track down some issues with memory leaks and
segfaults (c extension code - yuck) when I spotted the problem with
_global_lock and it's siblings.
I don't think _global_lock will be used by developers unless they are
developing a new session class. The function is undocumented, and unless
people read the code for _apachemodule.c or Session.py they will never
even be aware of it's existence.
The use cases that I see are:
1. Acquire a system wide global lock, used to lock the dbmsession file
for example: _global_lock(server, None, index=0)
2. Acqurie a session lock: _global_lock(server, sid)
3. Debugging locking issues: _global_lock(server, None, index)
where -1 < index < # of mutexes.
As you suggest, we could use index = index % (glb->nlocks-1)+1) rather
than check that the index is in a proper range. However, since an index
!= 0 would only be used in case 3, I think this would just make
debugging more difficult.
I'm not worried about deadlocks if we use index % nlocks. Anybody that
tries to acquire more than one lock in the same request risks a deadlock
anyway, no matter how _global_lock is called.
Anyway, the point of this fix is to eliminate a bug, not add a feature.
:) I'm not stuck on any particular solution, as long as it doesn't segfault.
Regards,
Jim
Nicolas Lehuen wrote:
Him Jim,
If we add a test, then the developers will depend on the number of
mutexes that are configured. Why not do what is already done in
_apachemodule.c line 398, that is to say compute the given index
modulo the number of mutexes and use the resulting index ? I'm afraid
this might be deadlock-prone, but so is the already existing code in
that case... :(
Regards,
Nicolas
2005/6/1, Jim Gallacher (JIRA) <[EMAIL PROTECTED]>:
[ http://issues.apache.org/jira/browse/MODPYTHON-58?page=all ]
Jim Gallacher updated MODPYTHON-58:
-----------------------------------
Attachment: apachemodule.c-jg20050601-1.diff
Patch to fix issue is attached.
_apache._global_lock results in segfault when index > number of mutexes
-----------------------------------------------------------------------
Key: MODPYTHON-58
URL: http://issues.apache.org/jira/browse/MODPYTHON-58
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4, 3.1.3, 3.2.0
Environment: All
Reporter: Jim Gallacher
Priority: Minor
Attachments: apachemodule.c-jg20050601-1.diff
All of the following calls will cause a segfault when the index is greater than
the number of global mutexes available or index < -1.
eg. 32 mutexes created on apache startup
index = 100
_apache._global_lock(req.server, None, index)
_global_unlock(req.server, None, index)
_apache._global_trylock(req.server, None, index)
For all of the corresponding functions in _apachemodule.c, the value of index
is not checked before using it to access the contents of the global array of
mutex locks.
eg.
rv = apr_global_mutex_lock(glb->g_locks[index]);
I'll attach a patch for all three functions that does this check.
eg.
if ((index >= (glb->nlocks)) || (index < -1)) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
"Index %d is out of range for number of global mutex
locks", index);
PyErr_SetString(PyExc_ValueError,
"Lock index is out of range for number of global mutex
locks");
return NULL;
}
--
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
