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:50 | Date Closed: | |
Priority: | Major | Regression? | No |
Status: | Open/New | Components: | 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. |