[test-results] [Bamboo] Asterisk > 1.8 - Solaris 10 - i686 > #83 has FAILED. Change made by 10 authors.

[Bamboo]

-------------- next part --------------
-----------------------------------------------------------------------
Asterisk > 1.8 - Solaris 10 - i686 > #83 failed.
-----------------------------------------------------------------------
Code has been updated by twilson, Russell Bryant, sruffell, jpeeler, rmudgett, bbryant, Paul Belanger, dvossel, Matthew Nicholson, Tilghman Lesher.
No failed tests found, a possible compilation error.

http://bamboo.asterisk.org/browse/AST-SOLARIS1032-83/


--------------
Failing Jobs
--------------
  - Default Job (Default Stage): No tests found.


--------------
Code Changes
--------------
jpeeler (294640):

>Merged revisions 294639 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>
>................
>  r294639 | jpeeler | 2010-11-11 13:31:00 -0600 (Thu, 11 Nov 2010) | 53 lines
>  
>  Merged revisions 294384 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.4
>  
>  ........
>    r294384 | jpeeler | 2010-11-09 11:37:59 -0600 (Tue, 09 Nov 2010) | 47 lines
>    
>    Fix a deadlock in device state change processing.
>    
>    Copied from some notes from the original author (Russell):
>    
>    Deadlock scenario:
>    Thread 1: device state change thread
>      Holds - rdlock on contexts
>      Holds - hints lock
>      Waiting on channels container lock
>    
>    Thread 2: SIP monitor thread
>      Holds the "iflock"
>      Holds a sip_pvt lock
>      Holds channel container lock
>      Waiting for a channel lock
>    
>    Thread 3: A channel thread (chan_local in this case)
>      Holds 2 channel locks acquired within app_dial
>      Holds a 3rd channel lock it got inside of chan_local
>      Holds a local_pvt lock
>      Waiting on a rdlock of the contexts lock
>    
>    A bunch of other threads waiting on a wrlock of the contexts lock
>    
>    
>    To address this deadlock, some locking order rules must be put in place and
>    enforced. Existing relevant rules:
>    
>    1) channel lock before a pvt lock
>    2) contexts lock before hints lock
>    3) channels container before a channel
>    
>    What's missing is some enforcement of the order when you involve more than any
>    two. To fix this problem, I put in some code that ensures that (at least in the
>    code paths involved in this bug) the locks in (3) come before the locks in (2).
>    To change the operation of thread 1 to comply, I converted the storage of hints
>    to an astobj2 container. This allows processing of hints without holding the
>    hints container lock. So, in the code path that led to thread 1's state, it no
>    longer holds either the contexts or hints lock while it attempts to lock the
>    channels container.
>    
>    (closes issue #18165)
>    Reported by: antonio
>    
>    ABE-2583
>  ........
>................
>

Tilghman Lesher (294569):

>Properly queue files with inotify(7).
>
>(closes issue #18089)
> Reported by: abelbeck
> Patches: 
>       20101021__issue18089.diff.txt uploaded by tilghman (license 14)
> Tested by: tilghman
>

jpeeler (293305):

>Modify sip_setoption to not complain about unknown options.
>
>This now behaves just like the other setoption callbacks. For the curious the
>offending option for the reporter was AST_OPTION_CHANNEL_WRITE which was getting
>passed due to a fix for chan_local in 286189.
>
>(closes issue #17985)
>Reported by: globalnetinc
>


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