[SR-Users] Memory leak in tm with push notifications

[Jurijs Ivolga]

Hi,

I think I have this issue and I'm using 4.4 and I can't use master for now.
I tried to cherry pick this 2 commits, but unfortunately it do not work.

For example commit 5fe2a1a1c67b550431dcae3c98701073f7edd953 make changes in
function t_continue_helper, but 4.4 do not has such function, it has with
slightly different name - t_continue.

Same commit add line 258 in src/modules/tm/t_suspend.c, but in 4.4 this
part of code is slightly different. There is no " t->flags &=
~T_ASYNC_CONTINUE; " line in same if statement.

There is no way to remove line 390 from same file, cause in 4.4 that part
of code differs quite a lot.

With second patch 72f5eaeeef0239ebd16a2d645b83e83eb1a2b506 there was much
less problems, but still, there is big difference in part of code near line
592 of this commit, but probably in 4.4 i just need to update line 527 and
change "UNREF_FREE(new_cell); " to " UNREF_FREE(new_cell, 0);"


Is it a worth to try to cherry pick this 2 commits or there are too much
changes between 4.4 and Master and no way to make this work properly?


Please advise.

Thank you!

With kind regards,

Jurijs

On Tue, Jun 12, 2018 at 3:25 PM, Ivaylo Markov <ivo at schupen.net> wrote:

> Just in case anyone runs into this kind of problem in the future - commits
> 72f5eaeeef0239ebd16a2d645b83e83eb1a2b506 and
> 5fe2a1a1c67b550431dcae3c98701073f7edd953 (currently in the master branch
> only) seem to fix this.
>
> On 05/28/2018 06:01 PM, Ivaylo Markov wrote:
>
> Hello,
>
> I am trying to set up Kamailio as a push notifications proxy, closely
> following the example in the "Kamailio in a Mobile World" presentation
> (https://www.slideshare.net/FedericoCabiddu/kamailioinamobileworld-51617342).
> I am running Debian 9 and Kamailio 5.1.3 from the official Debian
> repositories.
> I believe the main modules involved in the issue below are tm, tmx, and
> tsilo.
>
> Every call passing through the proxy leads to a small memory leak in the tm
> module - there is a large amount of "delayed free" memory cells from tm's
> internal hash table. At some point the shared memory runs out and Kamailio
> restarts. Using the "kamcmd corex.shm_summary" command I was able to see
> that the top users of shared memory are "tm: h_table.c: build_cell" and
> "core: core/sip_msg_clone.c: sip_msg_shm_clone" with the same allocation
> count.
>
> I experimented with removing different parts of the configuration and
> noticed that commenting out the "t_continue(...)" call in the "PUSHJOIN"
> route
> (see slide #22) prevents the leak from happening. Maybe something in that
> function is incrementing the reference counter to the hash table cell, but
> it is not decrementing the counter when done?
>
> I tried looking around the source code of the tm and tmx modules, but saw
> nothing suspicious. I also tried using gdb with a breakpoint in
> t_continue_helper (tm/t_suspend.c:166) hoping to see what else is accessing
> the htable cell, but was unable to find anything of use.
>
> Has someone encountered anything like this? Can you provide more directions
> on debuggin this? I can provide some bits of configuration, but an entire
> test setup would be rather difficult, unfortunately.
>
> Thank you for your time,
> Ivo
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180613/fae62c2c/attachment.html>