Summary:	ASTERISK-20537: Asterisk deadlocks between looking up extension from process_sdp and bridge execution from pbx_realtime
Reporter:	Yaroslav Radilov (yarikrad)	Labels:
Date Opened:	2012-10-09 00:32:42	Date Closed:	2013-11-10 20:31:39.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General PBX/pbx_realtime
Versions:	1.8.16.0	Frequency of Occurrence
Related Issues:	duplicates ASTERISK-21040 Deadlock involving chan_sip.c, pbx.c and autoservice.c, locking on chan and &conclock is duplicated by ASTERISK-21228 Deadlock in pbx_find_extension when attempting an autoservice stop due to holding the context lock
Environment:	Linux CentOs	Attachments:	( 0) backtrace-threads.txt ( 1) core-show-locks.txt
Description:	I have got lock on asterisk 1.8.16.0. Lock happens once week on incoming call. It happens in different points of dialplan. Files with backtrace and core show locks included. [mjordan edit]: Deadlock appears to be between {{ast_write}} called from bridge initiated from {{pbx_realtime}} and attempting to stop the autoservice on the channel (called from {{ast_exists_extension}} from {{process_sdp}}).  The problem here is that the autoservice waits indefinitely until the channel comes out of autoservice, which it can't do since the channel is already locked by {{chan_sip}}. The channel cannot be locked when calling {{ast_exists_extension}}. Quoting from the source header: {code} * \note It is possible for autoservice to be started and stopped on c during this * function call, it is important that c is not locked prior to calling this. Otherwise * a deadlock may occur {code}
Comments:	By: Yaroslav Radilov (yarikrad) 2012-10-09 00:36:01.782-0500 files By: Matt Jordan (mjordan) 2012-10-29 13:57:33.853-0500 Thank you for reporting this issue.  {{pbx_realtime}} is an extended support module, and as such, developer support for it comes primarily from the Asterisk developer community.  Response times may reflect that. By: Matt Jordan (mjordan) 2013-11-10 20:31:39.212-0600 Closing out as a duplicate of ASTERISK-21228. Since that issue has received more traffic, this issue will be tracked there. Thanks!