Summary:	ASTERISK-24614: Deadlock when DEBUG_THREADS compiler flag enabled
Reporter:	Richard Mudgett (rmudgett)	Labels:
Date Opened:	2014-12-12 16:12:47.000-0600	Date Closed:	2014-12-12 17:34:34.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/General
Versions:	1.8.32.1 11.14.2 12.7.2 13.0.2	Frequency of Occurrence	Occasional
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt ( 1) jira_asterisk_24614_v1.8.28cert.patch ( 2) jira_asterisk_24614_v1.8.patch ( 3) jira_asterisk_24614_v12.patch
Description:	There is a sporadical strange deadlock in where Certified Asterisk 1.8.28-cert2 is running with DEBUG_TRHEADS compiler flag enabled. In the backtrace log you will find thread 49 waiting for the reentrancy mutex which seems not to get unlocked by thread 7. When using Certified Asterisk 1.8.15-cert6 (DEBUG_THREADS enabled) instead this deadlock does not occur. After a look into the source code, it is most likely the changes of ASTERISK-22455 are responsible for this deadlock. In lock.c / int __ast_cond_wait() a pthread_mutex is copied which leads to undefined results since pthread_mutex is an opaque type. {noformat} ... } else if (t->tracking) {   pthread_mutex_t reentr_mutex_orig; ast_reentrancy_lock(lt); /* Restore lock tracking to what it was prior to the wait */ reentr_mutex_orig = lt->reentr_mutex; *lt = lt_orig; /* un-trash the mutex we just copied over */ lt->reentr_mutex = reentr_mutex_orig; ast_reentrancy_unlock(lt); ast_restore_lock_info(t); } ... {noformat} Thanks to Thomas Airmont for finding this obscure regression in the DEBUG_THREADS code.
Comments:	By: Richard Mudgett (rmudgett) 2014-12-12 16:36:53.343-0600 Edited to show only the threads indicated by the issue description. This backtrace is typical of the DEBUG_THREADS caused deadlock because a thread is stuck waiting for the ast_reentrancy_lock. By: Richard Mudgett (rmudgett) 2014-12-12 16:57:06.346-0600 Attaching patches for branches recently entering security fix only.