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: http://svn.digium.com/svn/asterisk/branches/1.4@105116 f38db490-d61c-443f-a65b-d21fe96a405b

1 files changed, 9 insertions, 5 deletions

diff --git a/main/utils.c b/main/utils.c
index f309d87a1..755789c72 100644
--- a/main/utils.c
+++ b/main/utils.c
@@ -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);
 }