[Home]

Summary:ASTERISK-27887: func_channel: Accessing CHANNEL(pjsip,call-id) may crash if the channel hangs up.
Reporter:art (art)Labels:pjsip
Date Opened:2018-05-31 02:42:50Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Functions/func_channel Resources/res_hep_rtcp
Versions:13.18.5 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Ubuntu 16.04.4 LTS Linux 4.4.0-119-generic Attachments:( 0) callid-bt-full.txt
Description:I save outgoing sipcallid of PJSIP channel with following dialplan:
{noformat}
exten => _+X.,n,Dial(PJSIP/1000@$1.2.3.4,,b(set-callidpvt^s^1))

[set-callidpvt]
exten => s,1,NoOp(Set callidpvt)
same => n,Set(MASTER_CHANNEL(CDR(sipcallidpvt))=${CHANNEL(pjsip,call-id)})
same => n,Return()
{noformat}

This crashes asterisk about once in a week in system with 45000 calls per day. Backtrace shows:
{noformat}
#0  0x00007f0351e69428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f0351e6b02a in __GI_abort () at abort.c:89
#2  0x00007f0351e61bd7 in __assert_fail_base (fmt=<optimized out>,
   assertion=assertion@entry=0x7f02eca7fa70 "!\"Calling pjlib from unknown/external thread. You must \" \"register external threads with pj_thread_register() \" \"before calling any pjlib functions.\"", file=file@entry=0x7f02eca7f8d3 "../src/pj/os_core_unix.c", line=line@entry=692,
   function=function@entry=0x7f02eca7fd08 "pj_thread_this") at assert.c:92
#3  0x00007f0351e61c82 in __GI___assert_fail (
   assertion=0x7f02eca7fa70 "!\"Calling pjlib from unknown/external thread. You must \" \"register external threads with pj_thread_register() \" \"before calling any pjlib functions.\"", file=0x7f02eca7f8d3 "../src/pj/os_core_unix.c", line=692, function=0x7f02eca7fd08 "pj_thread_this") at assert.c:101
{noformat}

My guess is that outgoing pjsip channel is closed/destroyed by some reason before channel sipcallid is read.
Comments:By: Asterisk Team (asteriskteam) 2018-05-31 02:42:51.298-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: art (art) 2018-05-31 02:44:21.836-0500

full backtrace
By: Richard Mudgett (rmudgett) 2018-05-31 13:29:36.397-0500

Are you using Homer for RTCP logging (res_hep_rtcp.so)?  The backtrace you provided is showing the pjproject assertion happening with a function call from within that module.

If you don't need Homer logging then don't load the res_hep modules.  Even with Homer disabled it still loads your system doing nothing.
By: art (art) 2018-05-31 13:43:02.948-0500

Not using it, but it seems to be loaded by default. I will unload hep modules, let see if that helps.
By: Richard Mudgett (rmudgett) 2018-06-01 12:51:09.201-0500

I'm opening this issue because there is enough information to say we need more protection in chan_pjsip for the CHANNEL function to protect against holding the session ref by a non-pjsip servant thread.  The session destructor needs to be executed by a pjsip servant thread when accessing pjproject things or those things need to be executed by an ast_sip_push_task_wait_servant() task function.

The provided backtrace shows that it was the res_hep_rtcp.so module asking for the CHANNEL(pjsip,call-id) string and not the reporter's dialplan call for the same information.

FYI: [~art] I don't think you can be using bundled pjproject since you have pjproject assertions enabled.
By: art (art) 2018-06-05 11:28:49.398-0500

I haven't complied this asterisk by myself. So I were not sure which pjproject it had.