[Home]

Summary:ASTERISK-25710: core: Crash when publishing message that variable has been set
Reporter:JoshE (n8ideas)Labels:
Date Opened:2016-01-20 10:46:20.000-0600Date Closed:2020-01-14 11:14:02.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/PBX
Versions:13.6.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) crash_verbose_log.txt
( 1) crashdialplan.txt
( 2) fullverbose.txt
( 3) publish_msg_crash.txt
Description:Seeing this crash about weekly with 13.6 and PJSIP.
Comments:By: Asterisk Team (asteriskteam) 2016-01-20 10:46:22.414-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: JoshE (n8ideas) 2016-01-20 10:46:45.987-0600

Backtrace attached.
By: Richard Mudgett (rmudgett) 2016-01-20 12:47:48.806-0600

It looks like you are attempting to execute the Read application on a hung up channel.  Read should not be executed in the h exten.
By: JoshE (n8ideas) 2016-01-20 13:00:22.260-0600

That's definitely not the case.  We don't have a Read in h or a hangup handler anywhere.  It's quite possible a hangup happened while waiting for a read, but it isn't in a hangup context.

Seems a bit extreme to crash even with a Read in a hangup context.
By: Rusty Newton (rnewton) 2016-01-20 15:20:22.535-0600

Do you have a debug log (or even without debug) leading up to the crash?

If you can get a debug log for the next crash that would be really helpful.
By: Rusty Newton (rnewton) 2016-01-20 15:20:45.615-0600

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: JoshE (n8ideas) 2016-01-20 15:27:30.821-0600

Also attaching the dialplan output at the time of the crash.  The ODBC errors are normal, but these appear abnormal to me:

[2016-01-20 09:05:58] ERROR[20777][C-000004e3] astobj2.c: bad magic number for object 0x7f16bc0ccd98. Object is likely destroyed.
[2016-01-20 09:05:58] ERROR[20777][C-000004e3] astobj2.c: user_data is NULL
[2016-01-20 09:05:58] ERROR[20777][C-000004e3] astobj2.c: user_data is NULL
By: Joshua C. Colp (jcolp) 2016-01-21 18:41:12.126-0600

More information is needed on this - the partial verbose log shows two threads operating on the same channel which is bad and would cause this. What it does not show is how it ended up there. The full log from when the channel came in, the dialplan in use, and how it operates is really needed to have any idea of how it happened.
By: JoshE (n8ideas) 2016-01-21 18:52:09.435-0600

Thanks for the quick response Joshua!  Attaching both the full verbose output from the call itself, as well as the dialplan.
By: Rusty Newton (rnewton) 2016-01-26 14:29:52.880-0600

[~jcolp] may have meant by "full log" - the full log as is shown in the logger.conf.sample file.

{noformat}
;full => notice,warning,error,debug,verbose,dtmf,fax
{noformat}

This is a better guide:
https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Because even with the right logger channels you still need to turn up core debug and vebosity levels as well.

Often the DEBUG statements are really helpful in this sort of scenario.


By: Asterisk Team (asteriskteam) 2016-02-10 12:00:22.365-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines