Details
-
Type:
Bug
-
Status: Closed
-
Severity:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.18.0, 1.8.19.1, 1.8.20.1
-
Component/s: Channels/chan_sip/General
-
Labels:None
-
Environment:CentOS release 5.5 (Final)
Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
2 GB RAM
VM Ware ESXI
-
Frequency of Occurrence:Frequent
Description
Asterisk is frequently segfaulting (several times per week) in __ast_queue_frame at at channel.c:1450.
This is a fairly busy call routing server with up to 120 calls at peak times. Calls come in on a SIP channel and are routed straight back out on another SIP channel. directmedia=yes.
There are about eleven lines of dialplan for each call:
Set("SIP/xxxx-0000044c", "TAG=xxxxx")
NoOp("SIP/xxxx-0000044c", "Call from x to y")
Gosub("SIP/xxxx-0000044c", "sub-set-group,s,1(xxxxx)
Set("SIP/xxxx-0000044c", "GROUP()=xxxxx")
NoOp("SIP/xxxx-0000044c", "xxxxx: Call 27")
Return("SIP/xxxx-0000044c", "")
Set("SIP/xxxx-0000044c", "CDR(accountcode)=xxxx")
Gosub("SIP/xxxx-0000044c", "sub-set-cli,xxx,1")
Set("SIP/xxxx-0000044c", "CALLERID(num)=nnnnnnnnnnnn")
Return("SIP/xxxx-0000044c", "")
Dial("SIP/xxxx-0000044c", "SIP/trunk/yyyy,300,C")
The problem does not appear to be load related. The segfault has happened with only 26 calls in progress.
The segfault has also happened after only 30 minutes of uptime and then not again for a few days.
We have seen the problem on three different VM's.
I have a feeling that the problem is only happening with calls from one source SIP trunk but I have been unable to prove this.
Program terminated with signal 11, Segmentation fault. #0 0x000000000046a961 in __ast_queue_frame (chan=0x0, fin=0x41d72f60, head=0, after=0x0) at channel.c:1450 1450 cur = AST_LIST_LAST(&chan->readq);
I have attached a backtrace. Please let me know if any further information is required.
Issue Links
- is duplicated by
-
ASTERISK-24305
Crash with astobj2.c: user_data is NULL
-
- Closed
-
For some reason, there isn't a channel in place when Asterisk handles this particular ACK.
Can you provide a DEBUG log, as well as a pcap showing the message traffic leading up to the crash? There may be a deeper issue here where the channel that is having direct media negotiated on it is getting disposed of improperly.