Summary:	ASTERISK-27860: [patch] res_pjsip: Register pjsip_transport_management not externally but internally.
Reporter:	Alexander Traud (traud)	Labels:	patch pjsip
Date Opened:	2018-05-17 00:29:50	Date Closed:	2018-05-18 14:49:09
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	13.21.0 15.4.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) pjsip_unload_2.patch
Description:	This issue was caused by [Commit 758409d|https://github.com/asterisk/asterisk/commit/758409de56f1bfc5e9b58230282f9a5382cb3846] (ASTERISK-27618). The module res_pjsip_transport_management got moved into res_pjsip itself. It is no longer an independent module with (un)load_module. Therefore, res_pjsip has to initialize and destroy this internal module itself. That was/is done correctly. However, Asterisk tracks items via reference counting. Previously, res_pjsip was required by res_pjsip_transport_management. Therefore in its load_module, it increased the reference count on res_pjsip. Now, it is an internal module. Therefore, when res_pjsip is unloaded, res_pjsip_transport_management must be unloaded. Consequently, the reference count may not be increased when  res_pjsip_transport_management is registered as internal module. The attached patch fixes this. *Steps to Reproduce* # an UNIX operating system, for example Ubuntu 18.04 LTS # {{sudo apt install build-essential pkg-config libedit-dev libjansson-dev libsqlite3-dev uuid-dev libxslt1-dev}} # {{wget downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz}} # {{tar -zxf ./asterisk\-*-current.tar.gz}} # {{cd ./asterisk\-*}} # {{./configure --with-pjproject-bundled}} # {{make menuselect.makeopts}} # {{./menuselect/menuselect --enable REF_DEBUG}} # {{make}} # {{sudo make install config basic-pbx}} # {{sudo stop service asterisk}} # {{asterisk -cd}} # {{core stop gracefully}} *Expected Result* Asterisk cleanly ending (0). *Actual Results* loader.c:652 modules_shutdown: Passing on res_pjsip.so: its use count is 1 loader.c:652 modules_shutdown: Passing on res_pjproject.so: its use count is 1 loader.c:652 modules_shutdown: Passing on res_sorcery_config.so: its use count is 12 loader.c:652 modules_shutdown: Passing on res_sorcery_memory.so: its use count is 2 loader.c:652 modules_shutdown: Passing on res_sorcery_astdb.so: its use count is 2 Some modules could not be unloaded, switching to fast shutdown *Approach* When a module leaks, one approach is to look at Menuselect and the dependencies. Every module which is required for another module, is not likely the cause of the leak. For example, the modules res_pjproject and res_sorcery_* are required to run the module res_pjsip. Therefore, the not-null reference count of res_pjsip.c is the likely candidate. Then, I went for the [Reference Counts Log| https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging#ReferenceCountDebugging-EnablingReferenceCountLogs] and looked at res_pjsip.c. Each unbalanced (un)register/(un)load is a candidate for a leak. In this case here, an unregister_service(.) was missing. In the source code, I placed a debug output into register_service(.) to determine which module comes directly via register_service_noref(.). *Note* Too many reference counts are a constant issue recently. All these can be found via the command-line interface (CLI) and {{core stop gracefully}}. End-users of Asterisk might not be aware that this is a bug or think this bug is not relevant because its symptoms are so obvious. Furthermore, analyzing such bugs afterwards is terrible time consuming because I do not know the area which was worked on. Therefore, I recommend to add a test case, so the command {{core stop gracefully}} actually works.
Comments:	By: Asterisk Team (asteriskteam) 2018-05-17 00:29:52.306-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: Friendly Automation (friendly-automation) 2018-05-18 14:49:10.729-0500 Change 9004 merged by Jenkins2: res_pjsip: Register pjsip_transport_management not externally but internally. [https://gerrit.asterisk.org/9004|https://gerrit.asterisk.org/9004] By: Friendly Automation (friendly-automation) 2018-05-18 14:51:19.665-0500 Change 9002 merged by Jenkins2: res_pjsip: Register pjsip_transport_management not externally but internally. [https://gerrit.asterisk.org/9002|https://gerrit.asterisk.org/9002] By: Friendly Automation (friendly-automation) 2018-05-18 14:54:34.851-0500 Change 9003 merged by Jenkins2: res_pjsip: Register pjsip_transport_management not externally but internally. [https://gerrit.asterisk.org/9003|https://gerrit.asterisk.org/9003]