Summary:ASTERISK-11043: Asterisk segfault coincides with the "locking" when attempting to receiving inbound calls
Reporter:furiousgeorge (furiousgeorge)Labels:
Date Opened:2007-12-14 16:51:22.000-0600Date Closed:2007-12-27 11:25:28.000-0600
Versions:Frequency of
Environment:Attachments:( 0) backtrace.txt
( 1) backtrace2.txt
( 2) more_gdb_output.txt
Description:Every few weeks, we stop getting incoming calls because after we call out via POTS and hangup the channel stays open and must be hung up on.  When this happens to one of our three FXO channels, it will soon happen to all of them.

When it happened this time I was lucky enough to have it coincide with a segfault and core dump shortly after the soft hangups.  Im hoping the two things are in some way related


I recently switched from TDM400p to sangoma's equivalents because I was hoping some of the weirdness i was experiencing would go away.  For the most part it did not.

I see that we are now up to version 1.4.15, so I will update soon, but this problem has existed for every version of 1.4.x ive tried.
Comments:By: Clod Patry (junky) 2007-12-17 02:19:53.000-0600

changed the summary, like asked in #asterisk-bugs@IRC.

By: Joshua C. Colp (jcolp) 2007-12-18 09:08:20.000-0600

Please attach the output of the following commands when the core dump is opened in gdb:

frame 0
print *p
print *msg
print msg

By: furiousgeorge (furiousgeorge) 2007-12-18 16:23:10.000-0600

file, ive attached the output of the commands as you requested.

Also, today, the lines "locked up" again.  I've always used 9 to force the use of a landline, and after my users do that once, the snom phones will automatically insert 9 into the number unless the user stops it from doing so (its the number guessing feature).

So, inadvertently, they have been using the landlines more today, and as I am discovering, the more we use chan zap, the greater the likelihood we lock some channels.

Here is the output of 'core show channels' today:
claudia*CLI> show channels
Channel              Location             State   Application(Data)
Zap/8-1              (None)               Up      Bridged Call(SIP/Carmen-008214

SIP/Carmen-00821410  919737325516@outboun Up      Dial(ZAP/g1/ww19737325516|60)

SIP/carmen-00817600  (None)               Up      Bridged Call(Zap/7-1)
Zap/7-1              s@inbound:3          Up      

SIP/carmen-008b94b0  (None)               Up      Bridged Call(Zap/5-1)

Zap/5-1              s@inbound:3          Up      Dial(zap/1&zap/2&sip/carmen&si

Zap/6-1              (None)               Up      Bridged Call(SIP/Carmen-b5321e
SIP/Carmen-b5321e90  919737325516@outboun Up      Dial(ZAP/g1/ww19737325516|60)
8 active channels (***Yet no one is on the phone!***)

It seems more often than not that the 919737325516 number is the culprit too!  am i going crazy?

To be honest, I dont care if asterisk crashes from time to time, as running it via safe_asterisk protects me.  Users just think a call was dropped.

On the other hand, this issue with the locking of zap channels is a major problem causing much frustration to all parties involved.  Im a little worried that the issues are not related now.

By: Digium Subversion (svnbot) 2007-12-27 11:23:45.000-0600

Repository: asterisk
Revision: 94905

U   branches/1.4/channels/chan_sip.c

r94905 | file | 2007-12-27 11:23:44 -0600 (Thu, 27 Dec 2007) | 4 lines

Use ast_strlen_zero to see if our_contact is set or not on the dialog. It is possible for it to be a pointer to NULL.
(closes issue ASTERISK-11043)
Reported by: FuriousGeorge



By: Digium Subversion (svnbot) 2007-12-27 11:25:28.000-0600

Repository: asterisk
Revision: 94908

_U  trunk/
U   trunk/channels/chan_sip.c

r94908 | file | 2007-12-27 11:25:28 -0600 (Thu, 27 Dec 2007) | 12 lines

Merged revisions 94905 via svnmerge from

r94905 | file | 2007-12-27 13:27:11 -0400 (Thu, 27 Dec 2007) | 4 lines

Use ast_strlen_zero to see if our_contact is set or not on the dialog. It is possible for it to be a pointer to NULL.
(closes issue ASTERISK-11043)
Reported by: FuriousGeorge