[sr-dev] [kamailio/kamailio] tm: prevent t_suspend memory leak (#2763)

Julien Chavanton notifications at github.com
Sat Jun 5 00:29:32 CEST 2021

When suspending while already in t_continue when processing a reply / suspending twice in a reply.

Thanks to @giavac  https://github.com/kamailio/kamailio/pull/2721 we can now suspend more then once in a reply route.

This is working well, however a memory leak was detected.

This modification is proposing a solution that will prevent calling `sip_msg_cloner` over an already twice over the same pointer, creating the memory leak.

<!-- Kamailio Pull Request Template -->

  - for detailed contributing guidelines, read:
  - 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)

I assume this is a non "breaking change" since it can only trigger in a very the specific case that was not supported anyway.
Conditions when this alternate behavior can trigger:
1- must be in t_suspend
2- must be in a reply `if (msg->first_line.type == SIP_REPLY) {`
3- must have an already cloned `if (t->uac[branch].reply) {`

An alternate solution would be to free everything in the cloned message and recreate it.

#### 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
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)

load test done that included connections, failures and timeouts while suspending multiple times.

 6(31) INFO: tm [t_suspend.c:126]: t_suspend(): [>>>SUSPEND<<<] cloning message !
53(78) INFO: tm [t_suspend.c:136]: t_suspend(): [>>>SUSPEND<<<] message already cloned, re-using ! 

Total 100000 INVITE calls sent in 1710825 ms at rate of 58/sec
Total 100000 connection responses received in 1714999 ms at rate of 58/sec:
>> Detailed connection responses received:
 - 200 connection responses:    24924     (OK)
 - 404 connection responses:    25145     (Not Found)
 - 408 connection responses:    24912     (Request Timeout)
 - 500 connection responses:    25019     (Internal Server Error)
>> Detailed disconnection responses received:
 - 200 disconnection responses:    24924     (OK)
 TOTAL responses:    24924 (rate=14/sec)

#### Description
<!-- Describe your changes in detail -->

You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * tm: prevent t_suspend memory leak

-- File Changes --

    M src/modules/tm/t_suspend.c (21)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20210604/0206775d/attachment-0001.htm>

More information about the sr-dev mailing list