Possible dispatcher module memory leak

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible dispatcher module memory leak

Fox, Chad

We have experienced an issue where a device in our dispatcher list becomes unavailable and the dispatcher has to begin probing that resource.

We noticed that the memory grows at a constant rate after this happens and until the device is brought back online.

Inspecting the memory allocated by shm_malloc we see that the leaked memory is made up of dlg_t objects and strings allocated via shm_str_dup.

Looking at the ds_check_timer() function we see where the dlg_t objects and strings are allocated by a call to new_dlg_uac from t_request_outside().

Is it the dispatcher module’s job to shm_free the dialog memory, or does tm free it on it’s own?

 

<modules/dispatcher/dispatch.c>  (openser 1.3.2)

 

void ds_check_timer(unsigned int ticks, void* param)

{

           

            dlg_t * dialog;   

           

            /* Iterate over the groups and the entries of each group: */

            for(list = _ds_list; list!= NULL; list= list->next)

            {

                        for(j=0; j<list->nr; j++)

                        {

                                    /* If the Flag of the entry has "Probing set, send a probe:   */

                                    if ((list->dlist[j].flags&DS_PROBING_DST) > 0)

                                    {

                                                …

 

                                                /* Execute the Dialog using the "req_outside"-Method of the

                                                 * TM-Module.

                                                 * req_outside(str* m, str* t, str* f, str* h, str* b,

                                                 *                      dlg_t** d, transaction_cb c, void* cp); */

                                                if (tmb.t_request_outside(&ds_ping_method,

                                                                                    &list->dlist[j].uri,

                                                                                    &ds_ping_from,

                                                                                    NULL,

                                                                                    NULL,

                                                                                    &dialog,

                                                                                    ds_options_callback,

                                                                                    (void*)(long)list->id) < 0) {

                                                            LM_ERR("unable to execute dialog\n");

                                                }

                                    }

                        }

            }

}

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Possible dispatcher module memory leak

Bogdan-Andrei Iancu
Hi Chad,

Thank you for the report - I made a check and I can confirm your sayings
about the leak. I will verify why a dialog tm function is sent and not a
simple one.
I will come back to you asap.

Regards,
Bogdan

Fox, Chad wrote:

>
> We have experienced an issue where a device in our dispatcher list
> becomes unavailable and the dispatcher has to begin probing that resource.
>
> We noticed that the memory grows at a constant rate after this happens
> and until the device is brought back online.
>
> Inspecting the memory allocated by shm_malloc we see that the leaked
> memory is made up of dlg_t objects and strings allocated via shm_str_dup.
>
> Looking at the ds_check_timer() function we see where the dlg_t
> objects and strings are allocated by a call to new_dlg_uac from
> t_request_outside().
>
> Is it the dispatcher module’s job to shm_free the dialog memory, or
> does tm free it on it’s own?
>
> <modules/dispatcher/dispatch.c> (openser 1.3.2)
>
> void ds_check_timer(unsigned int ticks, void* param)
>
> {
>
> …
>
> dlg_t * dialog;
>
> …
>
> /* Iterate over the groups and the entries of each group: */
>
> for(list = _ds_list; list!= NULL; list= list->next)
>
> {
>
> for(j=0; j<list->nr; j++)
>
> {
>
> /* If the Flag of the entry has "Probing set, send a probe: */
>
> if ((list->dlist[j].flags&DS_PROBING_DST) > 0)
>
> {
>
> …
>
> /* Execute the Dialog using the "req_outside"-Method of the
>
> * TM-Module.
>
> * req_outside(str* m, str* t, str* f, str* h, str* b,
>
> * dlg_t** d, transaction_cb c, void* cp); */
>
> if (tmb.t_request_outside(&ds_ping_method,
>
> &list->dlist[j].uri,
>
> &ds_ping_from,
>
> NULL,
>
> NULL,
>
> &dialog,
>
> ds_options_callback,
>
> (void*)(long)list->id) < 0) {
>
> LM_ERR("unable to execute dialog\n");
>
> }
>
> }
>
> }
>
> }
>
> }
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Possible dispatcher module memory leak

Bogdan-Andrei Iancu
Hi Chad,

The fix is available on both trunk and 1.4 branches - please update from
svn (see revision 5087 / 5088) :

http://opensips.svn.sourceforge.net/opensips/?rev=5088&view=rev

Regards,
Bogdan

Bogdan-Andrei Iancu wrote:

> Hi Chad,
>
> Thank you for the report - I made a check and I can confirm your sayings
> about the leak. I will verify why a dialog tm function is sent and not a
> simple one.
> I will come back to you asap.
>
> Regards,
> Bogdan
>
> Fox, Chad wrote:
>  
>> We have experienced an issue where a device in our dispatcher list
>> becomes unavailable and the dispatcher has to begin probing that resource.
>>
>> We noticed that the memory grows at a constant rate after this happens
>> and until the device is brought back online.
>>
>> Inspecting the memory allocated by shm_malloc we see that the leaked
>> memory is made up of dlg_t objects and strings allocated via shm_str_dup.
>>
>> Looking at the ds_check_timer() function we see where the dlg_t
>> objects and strings are allocated by a call to new_dlg_uac from
>> t_request_outside().
>>
>> Is it the dispatcher module’s job to shm_free the dialog memory, or
>> does tm free it on it’s own?
>>
>> <modules/dispatcher/dispatch.c> (openser 1.3.2)
>>
>> void ds_check_timer(unsigned int ticks, void* param)
>>
>> {
>>
>> …
>>
>> dlg_t * dialog;
>>
>> …
>>
>> /* Iterate over the groups and the entries of each group: */
>>
>> for(list = _ds_list; list!= NULL; list= list->next)
>>
>> {
>>
>> for(j=0; j<list->nr; j++)
>>
>> {
>>
>> /* If the Flag of the entry has "Probing set, send a probe: */
>>
>> if ((list->dlist[j].flags&DS_PROBING_DST) > 0)
>>
>> {
>>
>> …
>>
>> /* Execute the Dialog using the "req_outside"-Method of the
>>
>> * TM-Module.
>>
>> * req_outside(str* m, str* t, str* f, str* h, str* b,
>>
>> * dlg_t** d, transaction_cb c, void* cp); */
>>
>> if (tmb.t_request_outside(&ds_ping_method,
>>
>> &list->dlist[j].uri,
>>
>> &ds_ping_from,
>>
>> NULL,
>>
>> NULL,
>>
>> &dialog,
>>
>> ds_options_callback,
>>
>> (void*)(long)list->id) < 0) {
>>
>> LM_ERR("unable to execute dialog\n");
>>
>> }
>>
>> }
>>
>> }
>>
>> }
>>
>> }
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>  
>>    
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users