[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