[test-results] [Bamboo] Asterisk - Team Branches > Pimp My SIP > #203 has FAILED (4 tests failed, no failures were new). Change made by root.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - Team Branches > Pimp My SIP > #203 failed.
-----------------------------------------------------------------------
Code has been updated by root.
1/2 jobs failed, with 4 failing tests, no failures were new.

http://bamboo.asterisk.org/browse/ASTTEAM-PIMPMYSIP-203/


--------------
Failing Jobs
--------------
  - Asterisk 1.8 CentOS 6 32-Bit (CentOS 6): 4 of 251 tests failed.



--------------
Code Changes
--------------
root (383844):

>Multiple revisions 383837-383838,383841
>
>........
>  r383837 | russell | 2013-03-25 20:38:56 -0500 (Mon, 25 Mar 2013) | 19 lines
>  
>  Fix multi-station answer race condition.
>  
>  When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
>  make outbound calls to the stations that have that trunk.  If more than
>  one station answers the call at the same time, all channels other than
>  the first one to answer are left in a bad state.  The channel gets
>  leaked, is not connected to anything, and there's no way to get rid of
>  it.
>  
>  We now properly clean up these losing channels by hanging up on them.
>  Since they lost the race, as we process their answer, there is no
>  ringing trunk for them to answer.
>  ........
>  
>  Merged revisions 383835 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>  ........
>  
>  Merged revisions 383836 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>  r383838 | russell | 2013-03-25 20:46:39 -0500 (Mon, 25 Mar 2013) | 7 lines
>  
>  Suppress compiler warning.
>  
>  This code caused a compiler warning when --enable-dev-mode was not used.
>  The warning was that this variable was set but not used.  That was indeed
>  the case as the only place this is used is as an argument to SKINNY_DEBUG
>  which is compiled out when not in dev mode.
>........
>  r383841 | mjordan | 2013-03-25 20:58:45 -0500 (Mon, 25 Mar 2013) | 22 lines
>  
>  Resolve deadlock between pending CDR and batch CDR locks
>  
>  r375757 attempted to resolve a race condition between multiple submissions of
>  CDRs while in batch mode from attempting to destroy the scheduled batch
>  submission by extending the batch CDR lock. Unfortunately, this causes a
>  deadlock between the pending CDR lock and the batch CDR lock. This patch
>  resolves the intent of r375757 by simply providing a new lock that protects
>  the scheduling of the batches. The original batch CDR lock is kept to protect
>  manipulation of the batch CDR settings, but has been placed such that it
>  is not held when the pending lock is held.
>  
>  Thanks to Chase Venters for providing lock analysis on the issue.
>  
>  (issue ASTERISK-21162)
>  Reported by: Chase Venters
>  ........
>  
>  Merged revisions 383839 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>  ........
>  
>  Merged revisions 383840 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>
>Merged revisions 383837-383838,383841 from file:///srv/subversion/repos/asterisk/trunk
>



--------------
Tests
--------------
Existing Test Failures (4)
   - AsteriskTestSuite: S/channels/gulp/basic calls/incoming/nominal/authed/md5/ident by host
   - AsteriskTestSuite: S/channels/gulp/basic calls/incoming/nominal/authed/md5/ident by user
   - AsteriskTestSuite: S/channels/gulp/basic calls/incoming/nominal/authed/userpass/ident by host
   - AsteriskTestSuite: S/channels/gulp/basic calls/incoming/nominal/authed/userpass/ident by user

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20130326/6597e10a/attachment-0001.htm>