Summary:	ASTERISK-27481: Asterisk crashes when receiving REFER message on PJSIP channel
Reporter:	Mika Aalto (mikaa)	Labels:	pjsip
Date Opened:	2017-12-14 07:18:20.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	pjproject/pjsip Resources/res_pjsip_refer
Versions:	15.1.2	Frequency of Occurrence	Constant
Related Issues:	is duplicated by ASTERISK-27998 Segfault after REFER packet
Environment:		Attachments:	( 0) Asterisk_startup_log_with_debug.txt ( 1) Asterisk_start.txt ( 2) core.2883-brief.txt ( 3) core.2883-full.txt ( 4) core.2883-locks.txt ( 5) core.2883-thread1.txt ( 6) full ( 7) messages
Description:	Asterisk crashes in pj_stricmp function. Program terminated with signal 11, Segmentation fault. #0  0x00007fae84a54307 in pj_stricmp (str1=0x10, str2=0x7fae00039cd8) at ../include/pj/string_i.h:216 216    if (str1->slen == 0) { Stacktrace: Thread 1 (Thread 0x7f2fa014a700 (LWP 2914)): #0  0x00007f300bf3a305 in pj_stricmp (str1=0x10, str2=0x7f2fec001138) at ../include/pj/string_i.h:216 #1  0x00007f300be7889e in find_pkg (event_name=0x7f2fec001138) at ../src/pjsip-simple/evsub.c:392 #2  0x00007f300be79325 in evsub_create (dlg=0x7f2f882c85b8, role=PJSIP_ROLE_UAS, user_cb=0x7f300c1866e0 <xfer_user>, event=0x7f2fec001138, option=1, p_evsub=0x7f2fa01493a0) at ../src/pjsip-simple/evsub.c:766 #3  0x00007f300be79918 in pjsip_evsub_create_uas (dlg=0x7f2f882c85b8, user_cb=0x7f300c1866e0 <xfer_user>, rdata=0x7f2fec00ee78, option=1, p_evsub=0x7f2fa0149420) at ../src/pjsip-simple/evsub.c:960 #4  0x00007f300be73f98 in pjsip_xfer_create_uas (dlg=0x7f2f882c85b8, user_cb=0x7f2f68cd23c0 <refer_progress_evsub_cb>, rdata=0x7f2fec00ee78, p_evsub=0x7f2f882dc438) at ../src/pjsip-ua/sip_xfer.c:256 #5  0x00007f2f68accaa6 in refer_progress_alloc (session=0x7f2f88032158, rdata=0x7f2fec00ee78, progress=0x7f2fa0149600) at res_pjsip_refer.c:393 #6  0x00007f2f68acf30f in refer_incoming_refer_request (session=0x7f2f88032158, rdata=0x7f2fec00ee78) at res_pjsip_refer.c:1090 #7  0x00007f2f68acf716 in refer_incoming_request (session=0x7f2f88032158, rdata=0x7f2fec00ee78) at res_pjsip_refer.c:1140 #8  0x00007f2fa3df831a in handle_incoming_request (session=0x7f2f88032158, rdata=0x7f2fec00ee78) at res_pjsip_session.c:3157 #9  0x00007f2fa3df857b in handle_incoming (session=0x7f2f88032158, rdata=0x7f2fec00ee78, response_priority=AST_SIP_SESSION_AFTER_MEDIA) at res_pjsip_session.c:3190 #10 0x00007f2fa3df9098 in session_inv_on_tsx_state_changed (inv=0x7f2f882ca648, tsx=0x7f2f882d8638, e=0x7f2fa01498c0) at res_pjsip_session.c:3478 #11 0x00007f300be686f7 in mod_inv_on_tsx_state (tsx=0x7f2f882d8638, e=0x7f2fa01498c0) at ../src/pjsip-ua/sip_inv.c:739 #12 0x00007f300beb2a11 in pjsip_dlg_on_tsx_state (dlg=0x7f2f882c85b8, tsx=0x7f2f882d8638, e=0x7f2fa01498c0) at ../src/pjsip/sip_dialog.c:2064 #13 0x00007f300beb327f in mod_ua_on_tsx_state (tsx=0x7f2f882d8638, e=0x7f2fa01498c0) at ../src/pjsip/sip_ua_layer.c:178 #14 0x00007f300beab592 in tsx_set_state (tsx=0x7f2f882d8638, state=PJSIP_TSX_STATE_TRYING, event_src_type=PJSIP_EVENT_RX_MSG, event_src=0x7f2fec00ee78, flag=0) at ../src/pjsip/sip_transaction.c:1267 #15 0x00007f300bead50d in tsx_on_state_null (tsx=0x7f2f882d8638, event=0x7f2fa0149970) at ../src/pjsip/sip_transaction.c:2410 #16 0x00007f300beac4e8 in pjsip_tsx_recv_msg (tsx=0x7f2f882d8638, rdata=0x7f2fec00ee78) at ../src/pjsip/sip_transaction.c:1827 #17 0x00007f300beb2164 in pjsip_dlg_on_rx_request (dlg=0x7f2f882c85b8, rdata=0x7f2fec00ee78) at ../src/pjsip/sip_dialog.c:1711 #18 0x00007f300beb3d62 in mod_ua_on_rx_request (rdata=0x7f2fec00ee78) at ../src/pjsip/sip_ua_layer.c:704 #19 0x00007f300be919d1 in pjsip_endpt_process_rx_data (endpt=0x23b15f8, rdata=0x7f2fec00ee78, p=0x7f2fa3be01e0 <param.23503>, p_handled=0x7f2fa0149b74) at ../src/pjsip/sip_endpoint.c:887 #20 0x00007f2fa39b331f in distribute (data=0x7f2fec00ee78) at res_pjsip/pjsip_distributor.c:903 #21 0x0000000000606bf9 in ast_taskprocessor_execute (tps=0x7f2f882ca288) at taskprocessor.c:963 #22 0x000000000060fe03 in execute_tasks (data=0x7f2f882ca288) at threadpool.c:1322 #23 0x0000000000606bf9 in ast_taskprocessor_execute (tps=0x23ab918) at taskprocessor.c:963 #24 0x000000000060dd03 in threadpool_execute (pool=0x23ae288) at threadpool.c:351 #25 0x000000000060f6f1 in worker_active (worker=0x7f2f90000948) at threadpool.c:1105 #26 0x000000000060f491 in worker_start (arg=0x7f2f90000948) at threadpool.c:1024 #27 0x000000000061b9b1 in dummy_start (data=0x7f2f90000a60) at utils.c:1257 #28 0x00007f300a090e25 in start_thread () from /lib64/libpthread.so.0 #29 0x00007f300937034d in clone () from /lib64/libc.so.6
Comments:	By: Asterisk Team (asteriskteam) 2017-12-14 07:18:21.328-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: Joshua C. Colp (jcolp) 2017-12-22 07:33:35.462-0600 Can you also provide the output of your Asterisk at startup? Looking at the code makes it seem as though an event package is registered that has been unloaded or freed. By: Mika Aalto (mikaa) 2018-01-02 04:20:08.003-0600 Asterisk startup log attached to issue report. By: Joshua C. Colp (jcolp) 2018-01-02 05:41:30.255-0600 Please use "asterisk -vvvvvvgc" to start Asterisk up in your local console. As well you've marked this as constant, does it happen every time with every device or just this device? By: Mika Aalto (mikaa) 2018-01-10 02:22:42.939-0600 Added Asterisk startup log with -vvvvvvgc options By: Mika Aalto (mikaa) 2018-01-10 02:29:03.221-0600 It happens every time when blind transfer related REFER is received. I have tested only on one server but I don't think it's server (device) related problem. Server OS: CentOS Linux release 7.4.1708 (Core) \# uname -r -o -v 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 GNU/Linux By: Kevin Harwell (kharwell) 2018-01-10 13:26:20.124-0600 I believe I've duplicated your issue. It appears that you do not have res_pjsip_pubsub.so loaded.  Try loading that module and see if that fixes the problem. If you have disabled it via menuselect then enable it. If you have disabled (noload) it via modules.conf then allow it to load. By: Kevin Harwell (kharwell) 2018-01-10 13:29:07.109-0600 Opening this issue. While the above is a workaround Asterisk should not crash while transferring. Either there needs to be a way to allow transfers without the pubsub module loaded, or a dependency needs to be set on the refer module that makes it so the pubsub module is required/loaded if refer is loaded. By: Mika Aalto (mikaa) 2018-01-11 07:47:30.284-0600 Kevin your analysis is correct. Module res_pjsip_pubsub.so was not loaded and after loading that module Asterisk won't crash anymore when processing REFER. Tested with Asterisk version 15.1.5. Thank you Kevin very much for your help!