| Summary: | ASTERISK-26521: MemLeak: res/res_pjsip_session.c | ||
| Reporter: | Badalian Vyacheslav (slavon) | Labels: | |
| Date Opened: | 2016-10-29 08:29:36 | Date Closed: | 2017-10-19 08:50:13 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_pjsip_session |
| Versions: | 13.12.1 14.1.1 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: |
Asterisk git branch "13" {code} Direct leak of 1136 byte(s) in 2 object(s) allocated from: #0 0x7f415b98ad50 in __interceptor_calloc (/usr/local/lib64/libasan.so.3+0xc1d50) #1 0x494a87 in _ast_calloc /usr/src/asterisk/include/asterisk/utils.h:573 #2 0x495993 in internal_ao2_alloc /usr/src/asterisk/main/astobj2.c:532 #3 0x495d38 in __ao2_alloc /usr/src/asterisk/main/astobj2.c:617 #4 0x7f41463a9143 in ast_sip_session_alloc /usr/src/asterisk/res/res_pjsip_session.c:1422 #5 0x7f41463aa957 in ast_sip_session_create_outgoing /usr/src/asterisk/res/res_pjsip_session.c:1765 #6 0x7f41178bda91 in request /usr/src/asterisk/channels/chan_pjsip.c:1946 #7 0x7f4148f82397 in sync_task /usr/src/asterisk/res/res_pjsip.c:3904 #8 0x7cf3c9 in ast_taskprocessor_execute /usr/src/asterisk/main/taskprocessor.c:967 #9 0x7eb430 in execute_tasks /usr/src/asterisk/main/threadpool.c:1322 #10 0x7cf3c9 in ast_taskprocessor_execute /usr/src/asterisk/main/taskprocessor.c:967 #11 0x7e6a40 in threadpool_execute /usr/src/asterisk/main/threadpool.c:351 #12 0x7ea3fa in worker_active /usr/src/asterisk/main/threadpool.c:1105 #13 0x7e9f37 in worker_start /usr/src/asterisk/main/threadpool.c:1024 #14 0x807044 in dummy_start /usr/src/asterisk/main/utils.c:1235 #15 0x7f4159d960a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x80a3) {code} Looks like {{ast_sip_session_alloc}} and {{ast_sip_session_create_outgoing}} have {code} ao2_ref(session, +1); {code} but may be i mistake Found in tests: - tests/apps/dial/dial_parallel/dial_parallel_answer_cancel_cause. - tests/apps/queues/queue_member_forward - tests/bridge/hold_redirect Found using my test toolkit {code} # mkdir /tmp/asterisk_asan # docker run --rm -it -v /tmp/asterisk_asan:/tmp/asterisk_asan --name asterisk-asan-master slavon/docker-asterisk-testsute-asan:pjproject_2.5.5-testsute_master-asterisk_13 {code} | ||
| Comments: | By: Asterisk Team (asteriskteam) 2016-10-29 08:29:37.148-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: Matt Jordan (mjordan) 2016-11-02 15:33:57.753-0500 If there is a memory leak, it isn't due to that ref increase. That ref increase is counteracting the {{ao2_cleanup}} call in the {{RAII_VAR}} macro. Are you sure all of the channels are being hung up prior to those tests ending? If a channel is still in memory when the process starts to rip itself down, it's possible that the memory would be "leaked" as the channel may not be disposed of properly. By: Corey Farrell (coreyfarrell) 2017-10-19 08:50:13.445-0500 I've just run the 3 tests you mentioned against the latest revision of {{master}}. No leaks in any of them. Since this ticket was open I've submitted a bunch of fixes to allow REF_DEBUG testing of PJSIP - ASTERISK-27306. Mostly this fixed failures to properly shutdown but a couple of actual leaks were addressed by that issue as well. It's possible the leak you experienced was fixed by that. | ||