[SR-Users] Possible memory leak dealing with presence in kamailio

[Nuno Reis]

Hello all.

I'm consistently watching a memory increase in kamailio when dealing with
PRESENCE events, namely SIP PUBLISH events. The system eventually hangs
running out of memory.
This behavior is seen at least in kamailio 4.1 and 4.2. I'm currently using
the latest stable 4.2.2.
If I disable the SIP PUBLISH handling in kamailio i don't observe the issue
anymore but as a side effect I don't have presence (name BLFs) also.
What do you think can be the right approach here? Should I open an issue in
github for this? Should I run kamailio under valgrind for some time? Are
there any other possible debug hints here?
Please find attached a code snippet with the presence related parts I'm
using right now.
Looking forward to hear from you.

Best Regards,

--

*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nreis at wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
<http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
| www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>*

[image: Description: Description: WavecomSignature]
<http://www.wavecom.pt/pt/wavecom/premios.php>

[image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150112/41c4a64d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16423 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150112/41c4a64d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: presence.cfg
Type: application/octet-stream
Size: 3992 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150112/41c4a64d/attachment.obj>