[asterisk-bugs] [Asterisk 0015618]: Channel not locked when it should in local_attended_transfer

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15618 
====================================================================== 
Reported By:                lmsteffan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15618
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 209615 
Request Review:              
====================================================================== 
Date Submitted:             2009-07-30 18:58 CDT
Last Modified:              2009-07-31 10:20 CDT
====================================================================== 
Summary:                    Channel not locked when it should in
local_attended_transfer
Description: 
Right after performing the transfer, the target channel (target.chan1) is
unlocked. It is not locked again before performing the masquerade (although
aa comment says so).

Performing a relock of this channel leads to a deadlock with
&current->chan1. Trying to solve that deadlock led me to a bunch of astobj2
errors.
====================================================================== 

---------------------------------------------------------------------- 
 (0108469) mmichelson (administrator) - 2009-07-31 10:20
 https://issues.asterisk.org/view.php?id=15618#c108469 
---------------------------------------------------------------------- 
This function is a total mess.

When local_attended_transfer is entered, we hold the lock on
current->chan1 and its tech_pvt. Then, in sip_get_pvt_byid_locked, we lock
targetcall_pvt and targetcall_pvt->owner, which is the same as
target.chan1. A bit later, we unlock targetcall_pvt->owner (thankfully).

So at the point where the transfer has succeeded, we have current->chan1
and target.chan1 locked. ast_cel_report will attempt to lock target.chan2.
ast_do_masquerade expects target.chan1 to be locked and will lock whichever
channel is in target.chan1->masq, which may be either current->chan2 or
target.chan2 depending on whether the calls are bridged.

So, in summary, the following locks will be locked by this thread during
the transfer:

current->chan1
current->chan2 (maybe, if target.chan2 is NULL)
target.chan1
target.chan2 (maybe, if it is non-NULL)

I think I said this in #asterisk-dev, too. This is going to be *FUN*. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-07-31 10:20 mmichelson     Note Added: 0108469                          
======================================================================