<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [ x] Commit message has the format required by CONTRIBUTING guide - [ x] Commits are split per component (core, individual modules, libs, utils, ...) - [ x] Each component has a single commit (if not, squash them into one commit) - [ x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x ] Tested changes locally - [x ] Related to issue #4257
#### Description When the dispatcher module sends ping requests then these requests are executed in a dedicated process, which handles timers and called `slow timer`. If during this ping request AVP variables are allocated, then these vars are allocated within `slow timer` process and this memory is never released and continiously accumulates in/by this process. This change makes AVP vars being reset for every iteration of the `dispatcher` timer procedure (`ds_check_timer` function).
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4258
-- Commit Summary --
* dispatcher: fixed memory leak when avp is indirectly used
-- File Changes --
M src/modules/dispatcher/dispatch.c (1)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4258.patch https://github.com/kamailio/kamailio/pull/4258.diff
miconda left a comment (kamailio/kamailio#4258)
The dispatcher module does not allocate avps itself, are you using any event route to process the dispatcher keepalive where the avps are set?
ivanuschak left a comment (kamailio/kamailio#4258)
@miconda please take a look at the configuration in [this issue](https://github.com/kamailio/kamailio/issues/4257). Yes avp is allocated within `allow_address` function of the `permissions` module. This allocation occurs within `slow timer` process, which does not call avp release functions, so avp is allocated every time when the execution goes through `event_route[siptrace:msg]`. As an another solution I tried to change avp type in permissions module to `AVP_CLASS_GLOBAL`, but it did not help. I'd appreciate if you adviced on a better solution, because the current one does not seem to be perfect.
miconda left a comment (kamailio/kamailio#4258)
I pushed a commit to siptrace module (referenced above), which is the one executing the event route. Try with the latest git master branch and see if it is fixed.
sergey-safarov left a comment (kamailio/kamailio#4258)
I have tested curent master and see crash ``` (gdb) bt #0 0x0000ffffb9356274 in raise () from /lib64/libc.so.6 #1 0x0000ffffb9340a2c in abort () from /lib64/libc.so.6 #2 0x0000ffffb934fba0 in __assert_fail_base () from /lib64/libc.so.6 #3 0x0000ffffb934fc18 in __assert_fail () from /lib64/libc.so.6 #4 0x000000000079fbe0 in xavp_reset_list () at core/xavp.c:643 #5 0x000000000066acd0 in ksr_msg_env_reset () at core/receive.c:671 #6 0x0000ffffb86189a4 in siptrace_exec_evcb_msg (sto=0xffffd1765bd0) at siptrace.c:2272 #7 0x0000ffffb861b9f8 in siptrace_net_data_sent (evp=0xffffd1765fb8) at siptrace.c:2492 #8 0x000000000065d218 in sr_event_exec (type=15, evp=0xffffd1765fb8) at core/events.c:397 #9 0x0000ffffb877ae64 in msg_send_buffer (dst=0xffffb48a7a00, buf=0xffffb48a9870 "OPTIONS sip:[2600:1f1c:6d5:aa00::6]:5060;transport=tcp SIP/2.0\r\nVia: SIP/2.0/TCP [::1];branch=z9hG4bKe58c.7290ace", '0' <repeats 25 times>, ".0\r\nTo: sip:[2600:1f1c:6d5:aa00::6]:5060;transport=tcp\r\nFrom"..., len=420, flags=0) at ../../core/forward.h:353 #10 0x0000ffffb877c330 in send_pr_buffer (rb=0xffffb48a79b0, buf=0xffffb48a9870, len=420) at t_funcs.c:77 #11 0x0000ffffb873cd1c in send_prepared_request_impl (request=0xffffb48a79b0, retransmit=1, branch=0) at uac.c:715 #12 0x0000ffffb873e3f0 in t_uac_with_ids (uac_r=0xffffd1766528, ret_index=0x0, ret_label=0x0) at uac.c:801 #13 0x0000ffffb873e2d0 in t_uac (uac_r=0xffffd1766528) at uac.c:765 #14 0x0000ffffb87417c8 in request (uac_r=0xffffd1766528, ruri=0xffffb489d3f0, to=0xffffb489d3f0, from=0xffffd1766518, next_hop=0xffffd1766508) at uac.c:1147 #15 0x0000ffffb454a188 in ds_ping_set (node=0xffffb489d020) at dispatch.c:4205 #16 0x0000ffffb454b47c in ds_check_timer (ticks=45772414, param=0x0) at dispatch.c:4253 #17 0x000000000054bad4 in compat_old_handler (ti=732358630, tl=0xffffb489cd40, data=0xffffb489cd40) at core/timer.c:982 #18 0x000000000054c964 in slow_timer_main () at core/timer.c:1105 #19 0x00000000004367dc in main_loop () at main.c:2000 #20 0x000000000044411c in main (argc=5, argv=0xffffd1766d48) at main.c:3411 (gdb) f 4 #4 0x000000000079fbe0 in xavp_reset_list () at core/xavp.c:643 643 assert(_xavp_list_crt != 0); (gdb) list 638 } 639 640 641 void xavp_reset_list(void) 642 { 643 assert(_xavp_list_crt != 0); 644 645 if(_xavp_list_crt != &_xavp_list_head) 646 _xavp_list_crt = &_xavp_list_head; 647 xavp_destroy_list(_xavp_list_crt); ``` Full backtrace in the attached file [bt.txt](https://github.com/user-attachments/files/20642893/bt.txt)
miconda left a comment (kamailio/kamailio#4258)
I reworked the initial solution, can you try with latest git master branch?
sergey-safarov left a comment (kamailio/kamailio#4258)
No crush now, but memory leak still there
miconda left a comment (kamailio/kamailio#4258)
Try again with latest git master branch.
sergey-safarov left a comment (kamailio/kamailio#4258)
Looks like no memory leak now. Should we close this PR and the related issue?
Closed #4258.
miconda left a comment (kamailio/kamailio#4258)
Thanks for testing and reporting back!