[Home]

Summary:ASTERISK-18734: Asterisk crash in click-to-call scenario (SIP only)
Reporter:Abhishek Naidu (naidua)Labels:
Date Opened:2011-10-19 03:47:11Date Closed:2011-11-07 11:08:50.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:.Release/Targets
Versions:1.8.4 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Red Hat Linux 5.5.2 64 bit Attachments:( 0) backtrace.txt
( 1) backtrace-1.txt
( 2) gdb.txt
Description:Asterisk source 1.8.4.3 (release version) is downloaded from Asterisk.org and compiled on Red Hat Linux 5.5.2 64 bit
The Asterisk installation is used to support click-to-call scenario.
All calls are SIP calls only and configuration is such that media is always remotely bridged.
There is no NAT involved.

The click-to-call functionality is invoked from Java client application that relies on Asterisk-Java
Asterisk is connected to Cisco Call Manager using a SIP Trunk (via UDP)
Some scenarios involve delayed offer from Call Manager, during which Asterisk does not invoke the native bridging functionality. To overcome this, we rely on force bridging everytime to ensure that calls are always remotely bridged.

During the day there are about 250 calls placed
However, we have observed that Asterisk crashes after a call attempt is placed after about > 8hrs of inactivity.
So there is no load on the system apparantly when the crash occurs.
This behavior is seen in all the 4 crashes since the 10th October to date.
 

Please let me know if any addition information would help

Thank You for your time!

Comments:By: Abhishek Naidu (naidua) 2011-10-19 03:50:15.933-0500

Please let me know how I can upload the coredump file which is 21MB (>10MB)
By: Paul Belanger (pabelanger) 2011-10-19 09:38:04.048-0500

Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then:

make install

After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report.

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace


By: Abhishek Naidu (naidua) 2011-10-20 08:21:58.758-0500

Thanks Paul,

I will make the change as specified and get back.

/Abhishek

By: Abhishek Naidu (abhishek.naidu@gs.com) 2011-11-04 05:23:10.351-0500

backtrace.txt generated with command:
gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core.nytadla01.ny.fw.gs.com-2011-11-04T05\:38\:30-0400 > /tmp/backtrace.txt

backtrace-1.txt and gdb.txt generated with command:
gdb -se "asterisk" -c core.nytadla01.ny.fw.gs.com-2011-11-04T05\:38\:30-0400 | tee /tmp/backtrace-1.txt

By: Walter Doekes (wdoekes) 2011-11-07 03:03:42.172-0600

{noformat}

------------------------------------------------------------------------
r328608 | markm | 2011-07-18 14:35:57 +0200 (Mon, 18 Jul 2011) | 9 lines

If the sip private structure is null, sip_setoption() will defref the null pointer and crash.

Ideally, sip_setoption shouldn't be called if there is a lack of a sip private structure.  But this will fix a crash.

(closes issue ASTERISK-17909)
Reported by: Mark Murawski
Tested by: Mark Murawski
{noformat}

1.8.4 is released on 2011-05-09.