[Home]

Summary:ASTERISK-10368: Segfault in chan_sip.c
Reporter:lucius (lucius)Labels:
Date Opened:2007-09-22 04:29:37Date Closed:2011-06-07 14:00:58
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb_dump.10245.txt
( 1) gdb_dump.11983.txt
( 2) gdb_dump.8167.txt
Description:Asterisk segfault randomize once or twice per month.
I attached gdb output from ast_grap_core script.

My environment:

Asterisk 1.4.11
Slackware 10.2.0 (glibc-2.3.5)
Kernel 2.6.15.4 SMP
Hardware Compaq Proliant 1600

Comments:By: Tilghman Lesher (tilghman) 2007-09-22 08:35:03

I think the actual issue is that you ran out of thread stack space.  I have to ask why you're running a recursive macro that seems to recurse 6 levels deep (as indicated by your backtrace) before it actually calls Dial?
By: lucius (lucius) 2007-09-22 11:49:18

This is my macro

[macro-manydial]
exten => s,1,Dial(${ARG3},${ARG2},${ARG1})
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-BUSY,1,Macro(manydial,${ARG1},${ARG2},${ARG4})

and this is example call macro

exten => 70,1,Answer()
exten => 70,2,Macro(manydial,tT,30,SIP/katowice1,SIP/katowice2)
exten => 70,3,VoiceMail(u70@Oddzialy)
exten => 70,4,Hangup()

I don’t know, why asterisk call this macro recurse to 6 levels deep.
For me asterisk should call max to 2 levels.
By: Tilghman Lesher (tilghman) 2007-09-22 11:56:20

Yes, but that's not what you wrote.  Your call plan recurses infinitely and when you add a condition that tests for an exit condition, you will stop running out of stack space.

Consider what happens when both lines are busy.

I'm closing this out as a configuration issue.