[asterisk-bugs] [Asterisk 0010342]: On Mac OS X PowerPC, Asterisk 1.4.x stops bridging new calls shortly after start

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10342 
====================================================================== 
Reported By:                jcovert
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   10342
Category:                   Core/Portability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0-beta8 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-31-2007 09:10 CDT
Last Modified:              05-08-2008 19:57 CDT
====================================================================== 
Summary:                    On Mac OS X PowerPC, Asterisk 1.4.x stops bridging
new calls shortly after start
Description: 
I have unsuccessfully tried to get every 1.4.x version of Asterisk to work
on Mac OS X PowerPC, most recently Asterisk 1.4.9 on Mac OS X 10.4.10.

Asterisk starts up fine, and works for a short while.  But after about the
third or fourth bridged call (local sip soft client, SJphone, or locally
connected SIP ATAs Cisco ATA 186), RTP read too short errors start
ocurring, or other dead call problems.  It is still possible to connect to
IVRs within asterisk, and inbound IAX2 calls from a 1.2.22 version of
Asterisk to the 1.4.9 version still work, but originating SIP devices are
unable to reliably make outbound calls.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 05-08-08 19:57  
---------------------------------------------------------------------- 
All right, I have what hopefully will be great news. I believe I have
solved this issue. The situation I described above stopped happening when I
fixed up the configure script as in the patch configure.patch that I have
attached here.

So, I'll run you through what was happening. After experiencing the
apparent lock-up, I took a backtrace of the threads and found that there
were some that appeared to be stuck deep, waaaaay deep, in dns-related
system calls. What seemed odd to me was that the non-reentrant flavors of
these dns calls were being used. Since you had mentioned that this same
setup worked flawlessly in 1.2.22, I checked to see what was different
between the two. What I noticed was that a check that was being done at
compile-time in 1.2 had been moved to the configure script in 1.4. I
checked my config.log file and found that the check for the existence of
the function was failing even though it clearly did exist.

So, after some Googling and some configure-script voodoo, I finally was
able to get the script to properly detect the existence of the res_ninit
function. This appeared to solve the problem 100% for me. In addition, I
was unable to reproduce issue 10202 anymore after this change.

So, I ask you now to please test the attached configure.patch. It contains
a patch both for the configure file as well as the configure.ac file. While
it isn't imperative that you patch your configure.ac file, I am including
it for completeness. After patching, rerun configure and be sure that the
line "Checking for res_ninit...yes" appears. This line will appear towards
the bottom of the output, just little bit down from some lines that check
for the existence of certain compiler attributes. After that, just rebuild
Asterisk and hopefully you'll be bridging calls like a pro! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-08-08 19:57  putnopvut      Note Added: 0086648                          
======================================================================