[asterisk-bugs] [JIRA] (ASTERISK-24614) Deadlock when DEBUG_THREADS compiler flag enabled

[Richard Mudgett (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett reassigned ASTERISK-24614:
------------------------------------------

    Assignee: Richard Mudgett

> Deadlock when DEBUG_THREADS compiler flag enabled
> -------------------------------------------------
>
>                 Key: ASTERISK-24614
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24614
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 1.8.32.1, 11.14.2, 12.7.2, 13.0.2
>            Reporter: Richard Mudgett
>            Assignee: Richard Mudgett
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)