[asterisk-bugs] [JIRA] (ASTERISK-27860) [patch] res_pjsip: Register pjsip_transport_management not externally but internally.

[Alexander Traud (JIRA)]

Alexander Traud created ASTERISK-27860:
------------------------------------------

             Summary: [patch] res_pjsip: Register pjsip_transport_management not externally but internally.
                 Key: ASTERISK-27860
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27860
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Resources/res_pjsip
    Affects Versions: 13.21.0, 15.4.0
            Reporter: Alexander Traud


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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)