[asterisk-dev] [Code Review] SIP: INVITE w/Replaces deadlock fix

Russell Bryant russell at digium.com
Thu Sep 17 15:19:10 CDT 2009


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/371/#review1094
-----------------------------------------------------------

Ship it!


- Russell


On 2009-09-17 14:48:19, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/371/
> -----------------------------------------------------------
> 
> (Updated 2009-09-17 14:48:19)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch cleans up the locking logic in chan_sip.c's handle_invite_replaces() function as well as making use of ast_do_masquerade() rather than forcing the masquerade on an ast_read().  The code had several redundant unlocks that would result in 'freed more times than we've locked!' errors. I cleaned these up as well as moving all the unlock logic to the end of the function.  This patch should also resolve the issue people were having with the replacecall channel never being unlocked with one legged calls.
> 
> This is very tricky code, as far as I can tell through my testing and tracing back through the code, the function starts with 4 locks held, the the sip_pvt, it's channel, and the replace sip_pvt and it's channel.  The function should end with only the original sip_pvt being locked as it will be unlocked by sipsock_read().
> 
> 
> This addresses bug 0015151.
>     https://issues.asterisk.org/view.php?id=0015151
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 218511 
> 
> Diff: https://reviewboard.asterisk.org/r/371/diff
> 
> 
> Testing
> -------
> 
> Tested attended transfers using Replaces header.  Tried both waiting for transfer to pickup and then hanging up, as well as hanging up while transfer was still ringing.  Both work. no more mutex unlock errors.
> 
> 
> Thanks,
> 
> David
> 
>




More information about the asterisk-dev mailing list