Summary: | ASTERISK-26453: res_pjsip_config_wizard: Memory leak in module_unload | ||
Reporter: | Badalian Vyacheslav (slavon) | Labels: | |
Date Opened: | 2016-10-09 22:39:24 | Date Closed: | 2016-10-30 13:40:22 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | 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 |