| commit | 57d04fd1ea0c18f40e7944b7c80ceeb204b8dc49 | |
| author | russell <russell@614ede4d-c843-0410-af14-a771ab80d22e> | |
| Thu, 28 Feb 2008 22:23:05 +0000 (28 22:23 +0000) | ||
| committer | russell <russell@614ede4d-c843-0410-af14-a771ab80d22e> | |
| Thu, 28 Feb 2008 22:23:05 +0000 (28 22:23 +0000) | ||
| tree | 194e9a10bba4a163f43876568603e91233087932 | treesnapshot (tar.gz zip) |
| parent | 7196c2caf918a1ca642ef29f7c6770ec8b4cda43 | commitdiff |
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 614ede4d-c843-0410-af14-a771ab80d22e
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 614ede4d-c843-0410-af14-a771ab80d22e
| include/asterisk/lock.h | diffblobblamehistory | |
| main/utils.c | diffblobblamehistory |