[asterisk-bugs] [Asterisk 0015014]: Asterisk loses SIP phones, possible deadlock, 1.6.1.0

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=15014 
====================================================================== 
Reported By:                madkins
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15014
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.1.0 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-01 11:03 CDT
Last Modified:              2009-05-04 18:44 CDT
====================================================================== 
Summary:                    Asterisk loses SIP phones, possible deadlock,
1.6.1.0
Description: 
I have two Cisco 7905g SIP phones connected to an Asterisk 1.6.1.0 instance
running on a 64 bit Xen instance of Debian 4.0.  My initial configuration
was more complex, but I've removed a lot of the complexity searching for
the problem.

Basically, I can start the Asterisk server and pick up a SIP phone and
call either a test extension or the other phone.  Works fine.  If I leave
it alone for a time ... say over a long lunch or overnight ... I come back
and the phones won't connect to Asterisk.

This repeats reliably but at unknown intervals.

====================================================================== 

---------------------------------------------------------------------- 
 (0104183) madkins (reporter) - 2009-05-04 18:44
 http://bugs.digium.com/view.php?id=15014#c104183 
---------------------------------------------------------------------- 
on my desktop the main/loader.c load_modules() function shows (via trace
statements) a regular, pseudo-alphabetized order for modules in the modules
directory (autoload=yes).  This allows chan_iax2 to load prior to
res_timing_pthread which avoids the pipe filling up problem

on the server the same function shows a 'random' order for modules (again
autoload=yes) which just happens to always load res_timing_pthread prior to
chan_iax2 so that the timer is invoked during the iax load module code and
the pipe filling up occurs

i can't say why the order is different on the two systems

if i use 'preload => res_timing_pthread.so i can get the correct (?)
ordering on my deskto and i'm running a test now to see if it locks up as i
expect, it won't be done until tomorrow (bus schedule, sorry)

i suspect i could use 'preload => chan_iax2.so' on the server and get an
incorrect ordering that would avoid the lockup, but that seems like the
wrong solution

since i'm not currently using IAX for anything, i think i'm going to turn
it off in modules.conf for the nonce, which may well prevent the issue
entirely

hazarding a guess, it may be that if i actually had any IAX connections
their normal function would invoke the proper _disable_continuous and/or
_ack timer callback(s) and thus pull data from the full pipe, which would
work as everyone expects 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-04 18:44 madkins        Note Added: 0104183                          
======================================================================