[asterisk-bugs] [Asterisk 0011100]: deadlock in iax

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11100 
====================================================================== 
Reported By:                callguy
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   11100
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-28-2007 13:07 CDT
Last Modified:              11-14-2007 23:03 CST
====================================================================== 
Summary:                    deadlock in iax
Description: 
We are seeing the iax channel deadlock and cause asterisk to stop
processing calls intermittently. output of core show locks attached. 
====================================================================== 

---------------------------------------------------------------------- 
 callguy - 11-14-07 23:03  
---------------------------------------------------------------------- 
russell: we came up with a theory on this one that was inspired by what we
found in bug 11080. We were wondering if the looping of the message we see
when this condition occurs (example from previous bug) is actually just a
symptom of the deadlock, and actually irrelevant relative to the actual
problem: 

[Sep 26 18:56:18] NOTICE[10762]: chan_iax2.c:6521 socket_read: Out of idle
IAX2 threads for I/O, pausing!

So seeing the above from within socket_read() was a symptom of deadlock,
caused because we were unable to obtain a new lock, as all available ones
were consumed.

we noticed these functions: 
registry_authrequest
register_verify
update_registry   

get a lock, but were not unlocking on error condistions, and just jumping
to return_unref. so in the diff we added a ast_mutex_unlock here to make
sure all cases have unlocked. This was the only obvious thing we could
identify. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-14-07 23:03  callguy        Note Added: 0073668                          
======================================================================