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

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18031 
====================================================================== 
Reported By:                rain
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18031
Category:                   Applications/app_queue
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           Older 1.6.2 - please test a newer version 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-09-22 15:51 CDT
Last Modified:              2010-09-23 10:56 CDT
====================================================================== 
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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-23 10:56 lmadsen        Description Updated                          
2010-09-23 10:56 lmadsen        Additional Information Updated                  
 
======================================================================