[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:              06-23-2008 10:50 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 - 06-23-08 10:50  
---------------------------------------------------------------------- 
Yes, you definitely don't want to upload the core file here, because it is
way too big like you said, and it also is useless if ported to a different
machine. What you should do is look in the file doc/backtrace.txt for
instructions on how to obtain a backtrace from a core dump using gdb. If
you issue the "thread apply all bt" command in gdb, you'll get a backtrace
of all threads currently running. It may be a bit tricky to track down
which thread is actually looping, but using the debug info you have added
to poll.c, you should be able to match the address of pArray to the address
given in the backtrace. If you can isolate that one thread, and upload the
backtrace from that thread, that would be helpful. As far as passwords and
other information goes, I doubt that sort of thing will be included in the
backtrace you upload, but just in case, you may want to take a close look
and sanitize it prior to uploading. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-23-08 10:50  putnopvut      Note Added: 0089091                          
======================================================================