[asterisk-bugs] [Asterisk 0018031]: potential channel/queue deadlock when setqueuevar enabled

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18031 
====================================================================== 
Reported By:                rain
Assigned To:                bbryant
====================================================================== 
Project:                    Asterisk
Issue ID:                   18031
Category:                   Applications/app_queue
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     resolved
Asterisk Version:           Older 1.6.2 - please test a newer version 
JIRA:                       SWP-2290 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-09-22 15:51 CDT
Last Modified:              2010-11-19 15:40 CST
====================================================================== 
Summary:                    potential channel/queue deadlock when setqueuevar
enabled
Description: 
When setqueuevar is enabled in app_queue, the potential exists for one
thread to lock a call_queue structure with a channel lock held while
another thread locks the channel with the call_queue lock held.  The
resulting deadlock will end up crippling Asterisk since quite a few parts
of Asterisk will traverse the channel list.

At several points in app_queue (in my case, end_bridge_callback), a queue
will be locked before calling set_queue_variables (which pulls data
directly out of the queue structure); this is fine, but when setqueuevar is
actually enabled, the call to pbx_builtin_setvar_multiple will lock the
channel.  Meanwhile, another thread may be calling ast_do_masquerade() to
clone the same channel, resulting in a lock on the same channel
(clonechan.)  Later in the masquerade, the datastore fixup functions are
called, and queue_transfer_fixup's call to update_queue() will result in an
attempt to lock the related queue (or all queues if shared_lastcall is
enabled.)

This deadlock occurred for me on 1.6.2.6 but appears to present in
1.6.2.13 as well.  In my case, do_masquerade() got the channel lock while
end_bridge_callback() got the queue lock.
====================================================================== 

---------------------------------------------------------------------- 
 (0129001) svnbot (reporter) - 2010-11-19 15:40
 https://issues.asterisk.org/view.php?id=18031#c129001 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 295670

U   branches/1.8/apps/app_queue.c

------------------------------------------------------------------------
r295670 | bbryant | 2010-11-19 15:40:21 -0600 (Fri, 19 Nov 2010) | 8 lines

Patch for deadlock from ordering issue between channel/queue locks in
app_queue
(set_queue_variables).

(closes issue https://issues.asterisk.org/view.php?id=18031)
Reported by: rain

Review: https://reviewboard.asterisk.org/r/1018/

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-19 15:40 svnbot         Checkin                                      
2010-11-19 15:40 svnbot         Note Added: 0129001                          
2010-11-19 15:40 svnbot         Status                   acknowledged =>
assigned
2010-11-19 15:40 svnbot         Assigned To               => bbryant         
2010-11-19 15:40 svnbot         Status                   assigned => resolved
2010-11-19 15:40 svnbot         Resolution               open => fixed       
======================================================================