Summary:	ASTERISK-26397: manager: PresenceState action crashes Asterisk 14
Reporter:	Andrew Nagy (tm1000)	Labels:
Date Opened:	2016-09-21 13:25:39	Date Closed:	2016-09-22 08:45:11
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:	14.0.0-rc1	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bt.txt ( 1) bt13.11.2.txt
Description:	Seems there is an easy way to get Asterisk 14 RC1 to Core dump through AMI commands. This was also in beta2 (not sure about beta1) Command flow is {code} [root@freepbxdev1 ~]# telnet 127.0.0.1 5038 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Asterisk Call Manager/2.8.0 Action: login Username: admin Secret: <secret> Events: off Response: Success Message: Authentication accepted Action: PresenceState Provider: CustomPresence:1000 Connection closed by foreign host. /usr/sbin/safe_asterisk: line 164: 30181 Segmentation fault      (core dumped) nice -n $PRIORITY "${ASTSBINDIR}/asterisk" -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY} {code} I have also attached a backtrace.
Comments:	By: Asterisk Team (asteriskteam) 2016-09-21 13:25:40.109-0500 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: Andrew Nagy (tm1000) 2016-09-21 13:28:09.076-0500 Note that "CustomPresence:1000", Extension 1000 is present. It's a PJSIP extension. Not sure what would happen if it was Chan SIP or non-existent. By: Jason Parker (jparker) 2016-09-21 14:51:29.061-0500 I'm pretty sure I'm seeing this with 13.11.2 also.  I'm working on getting debug symbols for a proper backtrace, but see below! (gdb) bt #0  0x000000000054829a in action_presencestate () #1  0x000000000053c63e in process_message () #2  0x000000000053fb6c in session_do () #3  0x00000000005cd69d in handle_tcptls_connection () #4  0x00000000005dc38a in dummy_start () #5  0x00007f9c77b05dc5 in start_thread () from /lib64/libpthread.so.0 #6  0x00007f9c76de4ced in clone () from /lib64/libc.so.6 By: Joshua C. Colp (jcolp) 2016-09-21 14:57:30.124-0500 The code between 13 and 14 is substantially different, it's probably something different but in the same area. By: Corey Farrell (coreyfarrell) 2016-09-21 14:58:55.960-0500 The 'if (!msg) { return res; }' code path would leave subtype / message undefined. By: Joshua C. Colp (jcolp) 2016-09-21 15:03:35.827-0500 It returns an error response though. In that case the AMI code and other cases don't output the subtype or message. By: Joshua C. Colp (jcolp) 2016-09-21 15:04:06.947-0500 I've still put up a review for it though. By: Jason Parker (jparker) 2016-09-21 15:14:35.195-0500 Rob stopped sucking and gave me proper debuginfo packages.  Here's the crash in 13.11.2. By: Joshua C. Colp (jcolp) 2016-09-21 15:19:08.225-0500 Fix is also up for that.