[OpenSIPS-Users] Possible memory leak related to AVPs

Mickael Marrache mickaelmarrache at gmail.com
Mon Jun 22 18:22:43 CEST 2015


Hi Razvan,

I do the following:

static str my_avp_name = {NULL, 0};
static pv_spec_t my_avp;

static param_export_t params[] = {
.....
{ "my_avp", STR_PARAM, &my_avp_name.s}
};

static int mod_init(void) {
        ....
my_avp_name.len = strlen(my_avp_name.s);
        ....
        if(my_avp_name.s == NULL || my_avp_name.len == 0) {
return -1;
}
if (pv_parse_spec(&my_avp_name, &my_avp) == 0 || my_avp.type != PVT_AVP) {
return -1;
}
}

Then, when I want to set a value to my AVP (for example, for setting an
integer):

pv_value_t pvar_value;
pvar_value.flags = PV_VAL_INT|PV_TYPE_INT;
pvar_value.ri = some_integer;
if(pv_set_value(msg, &my_avp, (int)EQ_T, &pvar_value) < 0) {
goto error;
}

And, that's all. I don't detroy the AVP after use because the module can't
know the AVP is not used anymore. I can destroy the AVP in the script after
use but I thought it was handled automatically.

In the example I gave here, is the AVP attached to a transaction? What are
the conditions for an AVP to be attached to a transaction?

Thanks,
Mickael

On Mon, Jun 22, 2015 at 10:33 AM, Răzvan Crainea <razvan at opensips.org>
wrote:

>  Hi, Mickael!
>
> Both maps are relevant, because both of them contain id2name mappings. So
> you should definitely look into the avp_map too. Note that those mappings
> do not store AVPs, they only store the real name of the AVP, as you use in
> script, and they can be populated at startup (in this case they are stored
> in PKG) and runtime (stored in SHM).
> It depends when the AVP should be destroyed: if they are attached to the
> transaction (and they usually are), they are automatically destroyed by the
> tm module. Otherwise the module that uses them, should take care of that.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 06/18/2015 09:56 PM, Mickael Marrache wrote:
>
> Hi Razvan,
>
>  I looked at both avp_map and avp_map_shm. In our case, only avp_map_shm
> is relevant since the leak appears in shared memory. I only see 4 elements
> in this map while I can see a lot of remaining AVPs when looking at the
> memory dump created at shutdown using QM debug. Therefore, it looks like
> these AVPs are not in the map. Looking at the new_avp function in
> usr_avp.c, I don't see at any moment that an entry is added to the map for
> the new AVP.
>
>  (gdb) print avp_map_shm->avl_count
> $5 = 4
> (gdb) print avp_map->avl_count
> $6 = 140
>
>  Any idea?
>
>  At which moment during execution an AVP is destroyed? Is it required for
> modules returning values to script through AVPs to destroy these AVPs? or
> are they automatically destroyed?
>
>  Thanks,
> Mickael
>
> On Thu, Jun 18, 2015 at 7:33 PM, Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>>  Hi, Mickael!
>>
>> This is not entirely true - you can define AVPs with the integer value 0.
>> Those will have avp->flags == 0 and avp->data == 0.
>> What I'd do, is to note down the avp->id value of those AVPs and then try
>> to see their names. To do that, you'd have to look into the avp_map and
>> avp_map_shm maps to see the corresponding name for that id. Alternatively
>> you can call in your script the avp_print() method, which prints all the
>> AVPs for a specific transaction along with their id and names. Let me know
>> how this goes.
>>
>>  Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>>   On 06/18/2015 12:48 PM, Mickael Marrache wrote:
>>
>> To add more information, I remember there was no way to define an integer
>> AVP with value 0. I see a lot of such AVPs.
>>
>> On Thu, Jun 18, 2015 at 12:03 PM, Mickael Marrache <
>> <mickaelmarrache at gmail.com>mickaelmarrache at gmail.com> wrote:
>>
>>> Correction of my previous email.
>>>
>>>  When I said I found AVPs without data, I may be wrong. avp->flags == 0
>>> probably means the AVP data is an integer. So, that explains the weird
>>> values (e.g. 0x8000) I tried to interpret as memory addresses.
>>>
>>>  Mickael
>>>
>>> On Thu, Jun 18, 2015 at 11:12 AM, Mickael Marrache <
>>> <mickaelmarrache at gmail.com>mickaelmarrache at gmail.com> wrote:
>>>
>>>> Hi Razvan,
>>>>
>>>>  Here is what I've done.
>>>>
>>>>  I took a core dump of the attendant process. Then, I stopped OpenSIPS
>>>> so that it frees allocated fragments, and at the end lists all fragments
>>>> that are still allocated.
>>>>
>>>>  In this list of fragments, I can see a lot of AVPs.
>>>>
>>>>  I see some AVPs without data (avp->data == NULL, avp->flags == 0).
>>>> But something is weird, it looks like that all AVPs that don't have data
>>>> have the same id. It looks like duplicate AVPs (in different memory
>>>> fragments).
>>>>
>>>>  Some AVPs do have data and have a format that looks valid.
>>>>
>>>>  Some AVPs looks corrupted. For example, I found an AVP with same ID
>>>> as the AVPs without data, but avp->data == 0x8000 which looks completely
>>>> wrong.
>>>>
>>>>  Thanks,
>>>> Mickael
>>>>
>>>> On Thu, Jun 18, 2015 at 10:11 AM, Mickael Marrache <
>>>> <mickaelmarrache at gmail.com>mickaelmarrache at gmail.com> wrote:
>>>>
>>>>> Hi Razvan,
>>>>>
>>>>>  I created a core dump for the attendant process. Is it enough or we
>>>>> also need core dumps for other processes? Note that the leak appears in
>>>>> shared memory.
>>>>>
>>>>>  We do use QM debug for this version, this is how I discovered the
>>>>> remaining AVPs at shutdown where the remaining allocated memory fragments
>>>>> are listed.
>>>>>
>>>>>  Do you know where I should look for the AVPs in the core dump?
>>>>>
>>>>>  Thanks,
>>>>> Mickael
>>>>>
>>>>> On Tue, Jun 16, 2015 at 5:11 PM, Răzvan Crainea <
>>>>> <razvan at opensips.org>razvan at opensips.org> wrote:
>>>>>
>>>>>>  Hi, Mickael!
>>>>>>
>>>>>> I don't know what exactly might cause the leak. What you can do is to
>>>>>> try to get a core dump (using tools like gcore) during low (or unexisting)
>>>>>> traffic and try to see what do the AVPs that are leaking contain. Are you
>>>>>> using QM debug?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Răzvan Crainea
>>>>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>>>>
>>>>>>  On 05/27/2015 12:37 PM, Mickael Marrache wrote:
>>>>>>
>>>>>> Any idea? Is there something that may help finding the leak cause?
>>>>>>
>>>>>> On Tue, May 19, 2015 at 1:17 PM, Mickael Marrache <
>>>>>> <mickaelmarrache at gmail.com>mickaelmarrache at gmail.com> wrote:
>>>>>>
>>>>>>> Any idea what we should do?
>>>>>>>
>>>>>>>  I may be doing something wrong but I don't remember I had to take
>>>>>>> care of memory management when dealing with AVPs.
>>>>>>>
>>>>>>>  Am I right?
>>>>>>>
>>>>>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> 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/20150622/f43a5c70/attachment-0001.htm>


More information about the Users mailing list