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

Wed Jan 21 17:00:16 CET 2015

Hello all.

Just want to tell you that the problem remains even after the patch Daniel
add to the latest 4.2.
I've sent another email yesterday (partially quoted bellow) to the mailing
list which was already answered by Juha Heinanen in cc regarding an odd
behavior (seems odd to me) i'm seeing.

I've been testing presence module for a while and I do notice that
> presentity table grows endlessly over time.
> Each time a call is made a new record is added in presentity with a
> different etag.
> In documentation, namely developers guide we can read this:
>
> int etag_not_new;
> 	/*
> 	 *  0 - the standard mechanism (allocating new etag
> 			for each Publish)
> 	 *  1 - allocating an etag only
> 			for an initial Publish
> 	*/
>
> How can I tell the presence module in kamailio config to work using the
> second form of the above?
>

I have a small production environment with ~70 extensions and in less than
24H (~20H), the presentity table grew from 0 to about ~2000 records, pua
table grew to about ~850 records and kamailio memory usage grew from 600MB
to 2GB on a 4G Linux server.
Yesterday Juha said and I'll quote:

presence module does not do anything with calls.  it handles publish and
> subscriber requests and generates notifies.
>
> when publish is handled, it is the job of the publisher to place correct
> etag in subsequent refresh publish requests.
>
> -- juha

Here my publisher is Kamailio itself. Can someone elaborate a bit more on
this issue and maybe we can get to bottom of it?
Thanks.

Cheers,

--

*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>

On Thu, Jan 15, 2015 at 4:56 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

>  Hello,
>
> I applied the patch, with some adjustments. Now in master, to be
> backported to stable branches soon.
>
> Cheers,
> Daniel
>
>
> On 13/01/15 20:16, Nuno Reis wrote:
>
> Hi Kristian and Daniel.
>
>  Kristian, hhanks for you feedback and patch.
> I'll try your patch here and will let you know the outcome soon.
> Thanks again guys.
>
>  Cheers,
>
>  --
>
> *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>
>
>
>
> On Tue, Jan 13, 2015 at 10:00 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>>  Hello,
>>
>> thanks for the details and patch. I will try to look at later today.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 13/01/15 08:35, Kristian F. Høgh wrote:
>>
>>  Hi,
>>
>>
>>
>> I've been hunting a memory error in publish handling the last couple of
>> days.
>>
>> The error is on our old but good 3.1.x presence server.
>>
>> Using memory debug, I located the memory leak in modules/presence/hash.c,
>> function insert_phtable, line 492 (in trunk):
>>
>> p= (pres_entry_t*)shm_malloc(size);
>>
>>
>>
>> As far I can see there are two errors when deleting publish htable entries
>>
>> 1. When calling delete_phtable pres.event->type is used instead of
>> pres.event->evp->type
>>
>>
>>
>> 2. When creating publish hashtable, p->publ_count is not set. (defaults
>> to 0)
>>
>> In delete_phtable, the following code is present
>>
>> p->publ_count--;
>>
>> if(p->publ_count== 0)
>>
>> p->publ_count is probably decremented to -1 (unless the user have two
>> active dialogs)
>>
>>
>>
>> I attach a patch, which I would carefully test in a test environment :-)
>>
>>
>>
>> Regards,
>>
>> Kristian Høgh
>>
>> Uni-tel
>>
>>
>>
>>
>>
>> On Monday 12 January 2015 15:39:27 Nuno Reis wrote:
>>
>> > 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 <%2B351%20913907481> | 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 <%2B351%20309%20700%20225> | F. +351 234 919 191
>>
>> > *GPS
>>
>> >
>> <http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
>> <http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
>>
>> > | www.wavecom.pt <http://www.wavecom.pt/> <http://www.wavecom.pt/>**
>> <http://www.wavecom.pt/> <http://www.wavecom.pt/>*
>>
>> >
>>
>> > [image: Description: Description: WavecomSignature]
>>
>> > <http://www.wavecom.pt/pt/wavecom/premios.php>
>> <http://www.wavecom.pt/pt/wavecom/premios.php>
>>
>> >
>>
>> > [image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>
>> <http://www.wavecom.pt/pt/mail_eventos.php>
>>
>>
>>
>>
>>  _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150121/ee270147/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 16423 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150121/ee270147/attachment.png>
-------------- 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/20150121/ee270147/attachment-0001.png>