[OpenSIPS-Devel] [OpenSIPS/opensips] e2141a: mid_registrar_save(): Fix shm memleak with no t_re...

[Liviu Chircu]

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: e2141a3b66b4ffe2e01fb9ed27412c8532b09fb8
      https://github.com/OpenSIPS/opensips/commit/e2141a3b66b4ffe2e01fb9ed27412c8532b09fb8
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2020-11-11 (Wed, 11 Nov 2020)

  Changed paths:
    M modules/mid_registrar/save.c
    M modules/tm/t_hooks.h
    M parser/msg_parser.h

  Log Message:
  -----------
  mid_registrar_save(): Fix shm memleak with no t_relay()

Since mid_registrar_save() is stateful by definition, it needs the SIP
transaction to properly function, so always forcing its creation if the
REGISTER is about to be forwarded is not that significant of a change,
if any at all.

Thus, this patch fixes a SHM memleak on the following type of logic:

    mid_registrar_save();

    # script terminates without having created the transaction,
    # so mid_registrar's "prepped" data does not get freed on T deletion
    exit;

(cherry picked from commit b14a7eaff60b719c8b80af4f8bfdffe2bc7e995b)


  Commit: 979d188668b3e5e5f392a7ef92a0f99cf62cfd1a
      https://github.com/OpenSIPS/opensips/commit/979d188668b3e5e5f392a7ef92a0f99cf62cfd1a
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2020-11-11 (Wed, 11 Nov 2020)

  Changed paths:
    M modules/tm/tm.c

  Log Message:
  -----------
  tm: Fix transaction leakage with global onreply_route

Given that the opensips.cfg execution order for replies is:
    1) onreply_route (global)
    2) reply_received(), i.e. "tm" module scope
      2.1) onreply_route (branch)
      2.2) onreply_route (transaction)

... this patch fixes some transaction leaks where if the script developer
matches the current transaction within global onreply_route, e.g. with a
random statement such as xlog("$T_reply_code\n"), it would cause an
extra ref after a transaction matching operation would be performed yet
again (??) within reply_received(), as the "tm" scope begins executing.

The fix is to simply avoid transaction lookups when evaluating tm
variables within the non-transactional, global SIP reply route.

Credits to Bogdan-Andrei Iancu for suggesting this solution

(cherry picked from commit 3a25c0b28f9bffc5e6942a7a3f5484ef903e28f6)


Compare: https://github.com/OpenSIPS/opensips/compare/110e828e313f...979d188668b3