[OpenSIPS-Users] Potential memory leak in siptrace module

Steve Brisson steve.brisson at librestream.com
Thu Feb 1 12:30:03 EST 2018


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:bogdan at opensips.org]
Sent: Thursday, February 1, 2018 10:54 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Steve Brisson <steve.brisson at 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 at lists.opensips.org<mailto:Users at lists.opensips.org>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180201/17ef76f3/attachment.html>


More information about the Users mailing list