[OpenSIPS-Devel] Potential Package Memory Leak

[Ryan Bullock]

After some recent scripting changes we started getting the following
errors in our logs:

ERROR:core:do_action: memory allocation failure
ERROR:core:pv_set_ruri_user: do action failed
CRITICAL:core:mk_proxy: pkg memory allocation failure
.........
.........

Restarting opensips clears the issue for awhile.

System information:
Scientific Linux 6.1
Linux 2.6.32-220.4.1.el6.x86_64 #1 SMP Mon Jan 23 17:20:44 CST 2012
x86_64 x86_64 x86_64 GNU/Linux

Opensips Info (This is a bit older SVN of trunk, so unsure if this is
a known issue, I could not find one):
version: opensips 1.8.0-dev0-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_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.
svnrevision: 2:8527M
@(#) $Id: main.c 8506 2011-10-21 10:21:10Z vladut-paiu $
main.c compiled on 09:00:51 Jan  9 2012 with gcc 4.4.5

Opensips Startup options: "-u opensips -g opensips -m 2560 -M 100"

The big scripting changes that were made included storing the $rb of
the initial invite in a dialog variable (e.g
store_dlg_value("uac_body","$rb")) and the use of  append_to_reply()
(e.g. append_to_reply("Contact: $avp(contact)\r\nContent-Type:
application/sdp\r\n"))  with t_reply_with_body (e.g
t_reply_with_body("200", "OK", "$avp(uac_body)")) for an interop issue
were having.

While I would expect some increased memory usage (from storing $rb), I
do not think it should be using up all of our package memory.
Increasing package memory does appear to increase the time between
occurrences.

A memory dump from the last time we received these errors is availble at:
http://voipnerd.net/files/temp/opensips_memdump_dlgvar.log.bz2

Could someone please take a peak at the dump and ensure no leak is
happening? Or am I really using 100M of package memory?

We are planning an update to the latest 1.8 svn this weekend in hopes
that it may resolve this issue and bring us more current.

Please let me know if any additional information is required.

Thank you for your time.

Regards,

Ryan