Hi, Steve!

We actually found out a memory leak related to transactions tracing. Unfortunately the fix is not that easy, so it will take a while until we figure out the right way to solve this. I will keep you updated.


Best regards,
Răzvan

On 02/01/2018 07:30 PM, Steve Brisson wrote:
Hi,

In answer to your questions…

1.

$ opensips -V

version: opensips 2.3.2 (x86_64/linux)

flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT

ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535

poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.

main.c compiled on 15:38:40 Nov 24 2017 with gcc 5.4.0

I built from commit 9e497ea4ab03c67cb073bdf0dccef2b16bff80e2. I've since diff'd with the HEAD and I haven't seen any changes in the siptrace code that would have helped my particular issue.

2.

The call to sip_trace is in the main request route branch and it gets called for all requests.

input parameters:

sip_trace("tid", "d", "sip");

module config:

modparam("siptrace", "trace_on", 0)

modparam("siptrace", "trace_id", "[tid]uri=mysql://db-user:db-pass@db-host/db-name;table=sip_trace;")

*From:*Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
*Sent:* Thursday, February 1, 2018 10:54 AM
*To:* OpenSIPS users mailling list <users@lists.opensips.org>; Steve Brisson <steve.bris...@librestream.com>
*Subject:* Re: [OpenSIPS-Users] Potential memory leak in siptrace module

Hi Steve,

Thank you for your report. Could you provide the exact revision of your OpenSIPS (opensips -V) ?

Also what requests are you calling the sip_trace() for (INVITES ? PUBLISH? all?) and what are the input paramters ?

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

   http://www.opensips-solutions.com

OpenSIPS Summit 2018

   http://www.opensips.org/events/Summit-2018Amsterdam

On 01/31/2018 07:48 PM, Steve Brisson wrote:

    I've found that when I call the sip_trace method, in the main
    request routing block, the shmem used_size and fragments continually
    increases until the process crashes from an out of memory condition.

    By enabling memory alloc debugging, I confirmed that the leaked
    allocation is the shm_malloc of a trace_info_t structure in the
    sip_trace_w method [siptrace.c:1539]. This piece of memory is
    supposed to be freed in the dialog terminated callback but because
    of the logic in the sip_trace_w method, trace_flags gets modified to
    TRACE_TRANSACTION and the dialog callbacks are never registered.

    I haven't worked out the details of a proper fix yet. My workaround
    has been to remove the siptrace module from my config.

    OpenSIPS config details:

    opensips 2.3.2 (x86_64/linux)

    #siptrace module config

    modparam("siptrace", "trace_on", 0)

    modparam("siptrace", "trace_id",
    "[tid]uri=mysql://db-user:db-pass@db-host/db-name;table=sip_trace;")

    #siptrace method call in main request branch

    sip_trace("tid", "d", "sip");




    _______________________________________________

    Users mailing list

    Users@lists.opensips.org <mailto:Users@lists.opensips.org>

    http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Răzvan Crainea
OpenSIPS Core Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to