Fix a bug in the lock tracking code that was discovered by mmichelson. The issue

is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself.  So, do a sanity check to make sure that we're updating
lock info for the proper lock.

(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Russell Bryant
2008-02-28 22:23:05 +00:00
parent cdf21199a2
commit 12e5fb358a
2 changed files with 18 additions and 14 deletions

View File

@@ -633,7 +633,7 @@ void ast_store_lock_info(enum ast_lock_type type, const char *filename,
pthread_mutex_unlock(&lock_info->lock);
}
void ast_mark_lock_acquired(void)
void ast_mark_lock_acquired(void *lock_addr)
{
struct thr_lock_info *lock_info;
@@ -641,11 +641,13 @@ void ast_mark_lock_acquired(void)
return;
pthread_mutex_lock(&lock_info->lock);
lock_info->locks[lock_info->num_locks - 1].pending = 0;
if (lock_info->locks[lock_info->num_locks - 1].lock_addr == lock_addr) {
lock_info->locks[lock_info->num_locks - 1].pending = 0;
}
pthread_mutex_unlock(&lock_info->lock);
}
void ast_mark_lock_failed(void)
void ast_mark_lock_failed(void *lock_addr)
{
struct thr_lock_info *lock_info;
@@ -653,8 +655,10 @@ void ast_mark_lock_failed(void)
return;
pthread_mutex_lock(&lock_info->lock);
lock_info->locks[lock_info->num_locks - 1].pending = -1;
lock_info->locks[lock_info->num_locks - 1].times_locked--;
if (lock_info->locks[lock_info->num_locks - 1].lock_addr == lock_addr) {
lock_info->locks[lock_info->num_locks - 1].pending = -1;
lock_info->locks[lock_info->num_locks - 1].times_locked--;
}
pthread_mutex_unlock(&lock_info->lock);
}