Summary:	ASTERISK-13572: Deadlock between (MOH) ast_write on one end and local_hangup on other end (p->lock versus chan->lock_dont_use)
Reporter:	David Woolley (davidw)	Labels:
Date Opened:	2009-02-12 11:08:24.000-0600	Date Closed:	2009-02-12 12:02:58.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) coreshowlocks.txt ( 1) deadlockedthreadbts.txt
Description:	If an ast_write (in this specific case from music on hold) on one end of a local channel races with local_hangup, on the other end, a deadlock can arise in which the ast_write end holds chan->lock_dont_use and is waiting for p->lock and the local-hangup end has p->lock and is looping on trying to acquire chan->lock_dont_use. ****** ADDITIONAL INFORMATION ****** Although the one we have caught with thread debugging and no-optimise is as described, we suspect that others of our deadlocks don't involve the hangup. In the, to be attached, core show locks, thread ....5152 is doing the local hangup and thread ....0912 is doing the ast_write. The setup here is quite complex, in that we have a SIP phone, bridged to the local channel, which is logged in with agent_login, although it looks to me that one ought to be able to reproduce with simple music on hold.  The local channel was introduced so that we could inject DTMF digits to answer for the agent, from the AMI application, rather than using # on the phone.
Comments:	By: David Woolley (davidw) 2009-02-12 11:19:33.000-0600 Note that chan_local line numbers are off by two because of a local patch to make ringback tone be internally generated, which was done for another application of chan_local, and shouldn't be relevant here. I'm now adding short form backtraces of the two deadlocked threads. By: Joshua C. Colp (jcolp) 2009-02-12 12:02:57.000-0600 Closed as this is a duplicate of the already solved 13676.