[Home]

Summary:ASTERISK-26453: res_pjsip_config_wizard: Memory leak in module_unload
Reporter:Badalian Vyacheslav (slavon)Labels:
Date Opened:2016-10-09 22:39:24Date Closed:2016-10-30 13:40:22
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip
Versions:13.11.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Direct leak of 41 byte(s) in 1 object(s) allocated from:
   #0 0x7f50d1bbaba8 in __interceptor_malloc (/usr/local/lib64/libasan.so.3+0xc1ba8)
   #1 0x7f50bf95bb28 in _ast_malloc /usr/src/asterisk/include/asterisk/utils.h:547
   #2 0x7f50bf95bb28 in wizard_mapped_observer /usr/src/asterisk/res/res_pjsip_config_wizard.c:1138
   #3 0x77a68a in __ast_sorcery_insert_wizard_mapping /usr/src/asterisk/main/sorcery.c:1037
   #4 0x77a8f6 in __ast_sorcery_apply_wizard_mapping /usr/src/asterisk/main/sorcery.c:1047
   #5 0x77b8f9 in __ast_sorcery_object_register /usr/src/asterisk/main/sorcery.c:1174
   #6 0x7f50bf2bf68c in ast_res_pjsip_initialize_configuration res_pjsip/pjsip_configuration.c:1826
   #7 0x7f50bf29d038 in load_module /usr/src/asterisk/res/res_pjsip.c:4442
   #8 0x67441c in start_resource /usr/src/asterisk/main/loader.c:1026
   #9 0x676574 in load_resource_list /usr/src/asterisk/main/loader.c:1290
   #10 0x6774fc in load_modules /usr/src/asterisk/main/loader.c:1446
   #11 0x49444a in asterisk_daemon /usr/src/asterisk/main/asterisk.c:4615
   #12 0x493794 in main /usr/src/asterisk/main/asterisk.c:4372
   #13 0x7f50cef39b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)


Fix in gerrit
Comments:By: Asterisk Team (asteriskteam) 2016-10-09 22:39:25.079-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: Badalian Vyacheslav (slavon) 2016-10-09 22:41:45.771-0500

https://gerrit.asterisk.org/#/c/4047/

By: Badalian Vyacheslav (slavon) 2016-10-09 22:57:00.493-0500

Wrong fix... you all ready delete it in OTW_DELETE_CB, but it's don't work... i no have idea...

By: Badalian Vyacheslav (slavon) 2016-10-09 23:18:22.689-0500

Hmm... this is becouse AST_VECTOR_REMOVE_CMP_UNORDERED have {{break}} after first match....
You need to change {{vectors.h}} or do remove in while.... what's better?

By: Joshua C. Colp (jcolp) 2016-10-10 06:12:10.303-0500

Everywhere else that does something like this does it in a while loop, as generally what you are storing requires a reference decrement. Example:

{noformat}
       for (idx = 0; idx < AST_VECTOR_SIZE(&cap->preference_order); idx++) {
               struct format_cap_framed *framed = AST_VECTOR_GET(&cap->preference_order, idx);

               /* This will always be non-null, unlike formats */
               ao2_ref(framed, -1);
       }
       AST_VECTOR_FREE(&cap->preference_order);
{noformat}

By: Badalian Vyacheslav (slavon) 2016-10-10 11:04:34.722-0500

I think i have more elegant fix

https://gerrit.asterisk.org/#/c/4054/

By: Badalian Vyacheslav (slavon) 2016-10-30 13:40:23.038-0500

fixed in master and 13 branch