[Home]

Summary:ASTERISK-00059: cosmetic changes
Reporter:reptiles (reptiles)Labels:
Date Opened:2003-08-07 23:59:05Date Closed:2008-02-28 16:35:49.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cosmetic.patch
Description:mostly making the build process a bit quieter
and making mkdep so that it works on non-linux machines  8^)


****** ADDITIONAL INFORMATION ******

these patches are all cosmetic, and should not alter the resulting build.
Comments:By: Mark Spencer (markster) 2003-08-19 11:36:29

Merged
By: Digium Subversion (svnbot) 2008-02-28 16:19:20.000-0600

Repository: asterisk
Revision: 105116

U   branches/1.4/include/asterisk/lock.h
U   branches/1.4/main/utils.c

------------------------------------------------------------------------
r105116 | russell | 2008-02-28 16:19:19 -0600 (Thu, 28 Feb 2008) | 8 lines

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 ASTERISK-59 in BE-396, thanks Mark!)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=105116
By: Digium Subversion (svnbot) 2008-02-28 16:35:48.000-0600

Repository: asterisk
Revision: 105144

_U  trunk/
U   trunk/include/asterisk/lock.h
U   trunk/main/utils.c
U   trunk/utils/check_expr.c

------------------------------------------------------------------------
r105144 | russell | 2008-02-28 16:35:43 -0600 (Thu, 28 Feb 2008) | 16 lines

Merged revisions 105116 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines

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 ASTERISK-59 in BE-396, thanks Mark!)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=105144