Summary:ASTERISK-10753: SIP channel crashes on new call
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-11-13 11:07:51.000-0600Date Closed:2007-11-14 12:09:48.000-0600
Versions:Frequency of
Environment:Attachments:( 0) jt-sip-crash-20071112.txt
( 1) jt-sip-crash-20071112-2.txt
Description:Attempting a call into a SIP channel (with an invalid extension) causes Asterisk to crash.  Not sure if this is something that is specific to SIP, but I have no other channel types to test with at the moment.
Comments:By: Steve Murphy (murf) 2007-11-13 12:11:33.000-0600

According to the bt, It was in the act of building a trie when it died.

Could you please attach the "from-jt" context's contents to this bug, so I can reproduce the sequence of events that lead to this crash? You can warp/remove any proprietary info; but I need the extension names/patterns to be preserved intact.
It looks like it was working on _XXXXXXXXXXXXX*. when it died.

By: John Todd (jtodd) 2007-11-13 12:24:46.000-0600

attaching (in-line, sorry) extensions.conf bloc:

exten => 1,1,Answer
exten => 1,n(monkeys),Playback(tt-monkeys)
exten => 1,n,NoOp(Channel data pre-hangup: ${CHANNEL(rtpqos,audio,all)})
exten => 1,n,Hangup

exten => h,1,NoOp(Channel data post-hangup: ${CHANNEL(${CHANNEL})})
exten => h,n,Hangup

exten => 222,1,Dial(SIP/65579@ucla.edu,20)

exten => 111,1,Dial(SIP/s@jt-test.talkplus.com)

exten => 555,1,JabberSend(johnhtodd,testgtalkuser@gmail.com,Invisible man here sending a message)
exten => 555,n,Dial(Gtalk/johnhtodd/testgtalkuser@gmail.com)
exten => 555,n,Hangup
exten => 666,1,JabberSend(johnhtodd,othertestgmailuser@gmail.com,Invisible man here sending a message)
exten => 666,n,Hangup

exten => 777,1,Dial(SIP/16502499010@ms1.dev1)

exten => 888,1,NoOp(Starting ENUM stuff)
exten => 888,n,Set(Foo=${ENUMLOOKUP(43158058304,sip,,1,e164.arpa)})
exten => 888,n,NoOp(Hey, Foo is set to ${Foo})
exten => 888,n,Hangup

exten => 999,1,Set(SIP-USER=testgtalkuser)
exten => 999,n,Goto(gmail.com,s,1)

exten => 123,1,Dial(SIP/jtodd,20)
exten => 123,2,Hangup

exten => _1XXXXXXX.,1,Dial(IAX2/3015551212:notmyrealpassword@iax.binfone.com/${EXTEN})

exten => _X*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)
exten => _XXXXXXXXXXXXX*.,1,Goto(jt-isn,${EXTEN},1)

exten => _XXXXXXXXXXX,1,Dial(IAX2/3015551212/${EXTEN}))

By: Digium Subversion (svnbot) 2007-11-13 15:17:06.000-0600

Repository: asterisk
Revision: 89256

U   trunk/main/pbx.c

r89256 | murf | 2007-11-13 15:17:05 -0600 (Tue, 13 Nov 2007) | 1 line

closes issue ASTERISK-10753 -- where some fine points in the algorithm to build the tree needed to be corrected. Many thanks for the test case, jtodd

By: John Todd (jtodd) 2007-11-13 17:03:32.000-0600

Who said this was closed?  The opry ain't over until the fat coder dials.  Or something like that.

By: John Todd (jtodd) 2007-11-13 17:08:02.000-0600

Updated my SVN-TRUNK tree, recompiled.  This time, when sending a call through that context, it went to the wrong extension than I wished, due to a regexp ordering error.  But it didn't crash.  So I just split the context into two contexts and then used "includes" to put them in the right order.  Now I get a core dump again.  Included backtrace and extensions.conf as attached file.

By: John Todd (jtodd) 2007-11-13 18:55:42.000-0600

Murf indicated that there were changes to trunk, so I downloaded/compiled again and it seems to work this time.

By: John Todd (jtodd) 2007-11-13 18:56:12.000-0600

If this was not a SIP bug, perhaps Murf can re-categorize as he sees fit.

By: Steve Murphy (murf) 2007-11-14 12:09:48.000-0600

Ok, the second issue was trying to do hash table searches in a context where no extensions (and therefore, no hash tables) existed. Hadn't thought of that. A simple tweak and no more crashes. (89257)

Also found a bug that caused more than a few problems with trie formation: the m2 pointer needs to be zeroed every iteration thru the loop in the add-extension-to-tree func. Also, added some explanation and tightened up the cli-print-match-char-tree func. (89271)

And finally, in 89272, I shuffled the pattern weights a bit to make them less subject to pattern size, and to more strongly disfavor a . being matched. Now, the weight of a . is a function of the number of characters it matches.