[Home]

Summary:ASTERISK-24633: Asterisk crashing (awaiting backtrace)
Reporter:Mason Chase (moontius)Labels:
Date Opened:2014-12-20 04:45:05.000-0600Date Closed:2015-01-27 12:53:28.000-0600
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.15.0 13.1.0 Frequency of
Occurrence		Occasional
Related
Issues:
Environment:CentOS 6.5 64bitAttachments:( 0) DEBUG_LOG.txt
( 1) DEBUG_LOG_Asterisk_11.15.txt
Description:It seems asterisk erases the information about the ongoing call through Chan_SIP

This happens when :

A) This is right before the time Asterisk looses all SIP Dialog status related second leg on Bridges

Dec 23 03:29:24 callback01my kernel: asterisk[2652]: segfault at 9d0 ip 000000000048c120 sp 00007f9463ffc858 error 4 in asterisk[400000+208000]

Note:  At above point asterisk uptime 'core show uptime' is reset to zero, but strangely asterisk recover or continue to operate.

B) 20 or AMI listener is attached to asterisk on port 5038 and they all have filter as below:
C) AMI has filter of the UNIQUE ID of the channels and others:

'!Event: AGIExec'
'!Event: VarSet'
'!Event: RTCPSent'
'!Event: RTCPReceived'
'!Event: VarSet'

D) the call durations are usually above 10 minutes

E) the bridge is doing unlink before the hang-up and somehow asterisk must hold the information for SIP Dialog right before the hang-up

I tried asterisk 11.15 and the same result was there.

At this point ANSWEREDTIME is reported as NULL as well

F) At incident asterisk is loosing track of multiple calls at once.
Comments:By: Mason Chase (moontius) 2014-12-20 04:46:50.951-0600

Sip records
By: Michael L. Young (elguero) 2014-12-20 19:31:03.060-0600

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!


By: Mason Chase (moontius) 2014-12-22 23:59:06.509-0600

[Edit by Rusty - removed comment which was a duplicate of the Description field that you just modified]
By: Mason Chase (moontius) 2014-12-23 14:32:17.264-0600

If I set debug mode and recompile, using gdb and debug, shall asterisk be able to take heavy load to collect the logging information to resolve this issue?

While calls on my server are private and user confidential, how can I submit this logs to asterisk issue tracker and private which some form of NDA is agreed by asterisk?

I have to ensure our client's phone numbers and destination calls are safe and kept private.

Regards
By: Rusty Newton (rnewton) 2014-12-23 14:43:19.154-0600

I don't see an example of the "transaction does not exist" incident in the log.

Also, it looks like Asterisk is crashing?

{quote}
Dec 23 03:29:24 callback01my kernel: asterisk[2652]: segfault at 9d0 ip 000000000048c120 sp 00007f9463ffc858 error 4 in asterisk[400000+208000]
{quote}

Are you running Asterisk with -g and does it dump a core? If so, can you provide a backtrace? Please follow these instructions closely: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

{quote}
If I set debug mode and recompile, using gdb and debug, shall asterisk be able to take heavy load to collect the logging information to resolve this issue?
{quote}
There may be a little more load, but you should be fine. It is hard to know as it really depends on whether we are talking about tens of calls or thousands of calls.

If Asterisk is crashing.. that would explain why you are losing all your calls.

{quote}
Note: At above point asterisk uptime 'core show uptime' is reset to zero, but strangely asterisk recover or continue to operate.
{quote}
You probably have a script restarting Asterisk, like safe_asterisk.

We can't sign an NDA for your logs. We can lock the issue down to only bug marshals but that doesn't guarantee you anything legally.

{quote}
I have to ensure our client's phone numbers and destination calls are safe and kept private.
{quote}
You would need to manually scrub all private information from your files before uploading. This is what most users do.
By: Mason Chase (moontius) 2014-12-23 15:21:00.589-0600

I can see new file is created by asterisk : /tmp/core.callback01my-2014-12-23T23:31:29+0800

Is this something asterisk does when it crash?
By: Rusty Newton (rnewton) 2015-01-07 09:21:01.659-0600

{quote}
I can see new file is created by asterisk : /tmp/core.callback01my-2014-12-23T23:31:29+0800

Is this something asterisk does when it crash?
{quote}

It sounds like you haven't read my comment from "23/Dec/14 2:43 PM".  :)

Yes if Asterisk is run with the '-g' flag then it dumps a core upon crashing. As I requested in my previous comment, please follow the backtrace instructions to get a backtrace from your core file. If possible, please recompile and reinstall Asterisk following the directions in the backtrace instructions such that the backtrace will actually be useful.

Thanks!
By: Rusty Newton (rnewton) 2015-01-07 09:24:09.884-0600

In addition, be sure to follow this guide as well: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information and provide the resulting log. The log should include all of the logger channels detailed.

The log should correspond with the next backtrace that you provide. That means, the log should have been captured at the same time as Asterisk was running up until the crash. At that point, provide the logs and a backtrace from the *core* file that Asterisk dumps.
By: Matt Jordan (mjordan) 2015-01-27 12:53:19.175-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines