[Home]

Summary:ASTERISK-07367: [patch] Crash when an IAX2 call from another Asterisk server fails (due to missing application)
Reporter:seb7 (seb7)Labels:
Date Opened:2006-07-20 12:21:07Date Closed:2006-09-28 12:33:50
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax2-fix.diff
( 1) IAX_Crash_bt_28-09-06_#1.txt
( 2) IAX_Crash_Bug_Report_Logs_20-07-06_#1.txt
( 3) IAX_Crash_Log_20-07-06_#2_with_bt.txt
( 4) IAX_Crash_Log_20-07-06_#3_with_bt.txt
( 5) IAX_Crash_Log_22-09-06_#1_with_bt.txt
Description:An IAX2 call (with or without trunking) comes in from an Asterisk server (version 1.2.3, called IVRA2) to this Asterisk server (TRUNK r37857M from 18/07/06 - also had this issue with an older release of TRUNK), we call a non-existant application, and about 50% of the time we get a core dump.

This is the statement that seems to cause the crashes:
exten => 02077417070,2,SetCIDName(${CALLERIDNAME})
This was in here for historical reasons (upgrade from 1.0.x and then to 1.2.x: at the time I put it in, it was necessary to make the CIDName displayed to the called party (2nd leg on a bridged call)). Obviously I can remove the statement, but my concern is two-fold: (i) that other people will suffer the same problem; (ii) that actually this is a wider issue, and affects calls that fail in a certain way using IAx.

The more logging to the screen, the more likely this is to cause a crash. With console and messages logging set to verbose and debug 5, crash will be about 95% of the time. With verbose 3 and debug off, crash is about 15%. With verbose 0 and debug off, I can't get it to crash, i.e. less than 5% chance.

It doesn't just appear to a crash related to the number or speed of logging messages though, as I have tried doing things that generate lots of messages with logging turned up.

I have tried dialling into this number (02077417070) from my iaxComm soft phone, and it doesn't ever crash, so it is probably something about the connection to another Asterisk server via IAX2.

Sebastian

****** ADDITIONAL INFORMATION ******

This is the relevant part of my extensions.conf:

exten => 02077417070,1,NoOp(CALLERID is ${CALLERID}. CALLERIDNAME is ${CALLERIDNAME}. CALLERIDNUM is ${CALLERIDNUM})
exten => 02077417070,n,SetCIDName(${CALLERIDNAME})
exten => 02077417070,n,Ringing
exten => 02077417070,n,Answer
exten => 02077417070,n,BackGround(demo-congrats) ; Play a congratulatory message
exten => 02077417070,1,NoOp(CALLERID is ${CALLERID}. CALLERIDNAME is ${CALLERIDNAME}. CALLERIDNUM is ${CALLERIDNUM})
exten => 02077417070,n,SetCIDName(${CALLERIDNAME})
exten => 02077417070,n,Ringing
exten => 02077417070,n,Answer
exten => 02077417070,n,BackGround(demo-congrats) ; Play a congratulatory message

In most of my logs below (the earlier ones), it was:
exten => 02077417070,1,NoOp(CALLERID is ${CALLERID}. CALLERIDNAME is ${CALLERIDNAME}. CALLERIDNUM is ${CALLERIDNUM})
exten => 02077417070,2,SetCIDName(${CALLERIDNAME})
exten => 02077417070,3,Dial(IAX2/sebNP/tT)

Both cases produce crashes under the same logging levels when the call comes from IVRA2 via IAX2 with or without trunking.

The relevant part of iax.conf:
[IVRA2]
host=192.168.4.62
type=friend
context=iaxguests
auth=md5,rsa
secret=xxxxxxx
notransfer=no ; Disable IAX native transfer?
qualify=yes ; Make sure this peer is alive
qualifysmoothing = yes ; use an average of the last two PONG
qualifyfreqok = 60000 ; how frequently to ping the peer when
qualifyfreqnotok = 10000 ; how frequently to ping the peer when it's
accountcode=IVRA2
permit=0.0.0.0/0.0.0.0
language=uk ; Use UK english as default language
allow=alaw
allow=gsm
allow=all
;trunk=yes ; Tried with this uncommented too and get the same crashes.


Logs copied and pasted from the console:

-= snipped by vechers 07/21/06 =- see attachments.
Comments:By: seb7 (seb7) 2006-07-20 12:22:06

Ouch. Perhaps I should have attached these logs?

By: Serge Vecher (serge-v) 2006-07-20 13:16:53

not perhaps, for sure! ;) Please move them to attachments and I will adjust the 'additional info' field.

By: seb7 (seb7) 2006-07-21 03:40:28

Logs moved to attachments (but not config info).

Everything after here:

Logs copied and pasted from the console:
=======================================

can be deleted from the 'additional info' field, and this changed to "Logs copied and pasted from the console are attached."

Also the end of my report was truncated, but the only thing that is not now in the attachments is this paragraph:

If you want more logs, I don't have any problems in generating them. I also have some more core dumps from later logs. I can recompile with any other flags if it is helpful.

Sebastian

By: Serge Vecher (serge-v) 2006-09-01 14:32:00

1) what modifications have you done to the source?
2) try the latest trunk? unmodified, please.

By: seb7 (seb7) 2006-09-05 06:50:50

1) No modifications.
2) Tried latest (unmodified) trunk - yesterday's - r41974, and it still crashed - it was actually the first call into asterisk, verbosity was at 3, debug was on but only at 0. This was with compiler optimisations on though.

By: Serge Vecher (serge-v) 2006-09-20 11:41:48

Seb7: you need to attach new bt's from the latest trunk built without compiler optimizations.

By: seb7 (seb7) 2006-09-22 10:39:42

Retested on asterisk-1.4.0-beta2 compiled without optimizations and bt's submitted.

I also have another core I can analyse that happened about 15 minutes later if you want. The core I have just supplied the bt for had core debug on (and set to 0) in the console, whereas the later one does not have any core debug on. However, the bt (normal) looks the same.

By: seb7 (seb7) 2006-09-27 03:58:33

I wonder if 4 of the backtraces from issue 7885 are also related?

The ones I have listed in my comment (# 52100) as: problem (b) the IAX2 seg fault from bt #2 (07-SEP-06 09:02), #4 (#1 on 25-SEP-06), ASTERISK-1 (#2 on 25-SEP-06), ASTERISK-2 (#3 on 25-SEP-06), ASTERISK-3 (#1 on 26-SEP-06). The architecture there is a bit different - it's the server that is doing the Zap to IAX2 convertion that crashes (and not the IAX2 termination server), and here it is the IAX2 termination server that crashes and not the server doing to the Zap to IAX2 convertion. However, in both cases, the one that crashes is running trunk, and the one that doesn't is running 1.2.x.

By: Joshua C. Colp (jcolp) 2006-09-27 12:05:41

Please try the latest revision of the 1.4 branch or wait for the next 1.4 beta release, a change I put in at revision 43783 may have fixed this.

By: seb7 (seb7) 2006-09-28 04:50:11

Retested with SVN-branch-1.4-r43844 and I get the same crash. The backtrace looks the same as before.

By: Serge Vecher (serge-v) 2006-09-28 09:38:11

seb7: do attach the new bt please

By: seb7 (seb7) 2006-09-28 10:15:35

New bt uploaded from this morning.

By: Joshua C. Colp (jcolp) 2006-09-28 11:05:12

Please try the attached patch. Thanks!

By: seb7 (seb7) 2006-09-28 12:01:19

Hurrah! The attached patch seems to cure the crash! I can no longer cause a crash using the method I have used so far (even turning up debug to the max).

Thanks, file.

By: Joshua C. Colp (jcolp) 2006-09-28 12:33:49

Fixed in 1.4 as of revision 43915 and trunk as of revision 43917. Thanks!