[OpenSIPS-Users] Possible memory leak related to AVPs

Mon Jun 22 18:28:54 CEST 2015

Looking for example at the DIALPLAN module, it looks like the same
procedure is followed, so I don't see anything special I'm doing here.

On Mon, Jun 22, 2015 at 7:22 PM, Mickael Marrache <mickaelmarrache at gmail.com
> wrote:

> 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/e1e1ad2d/attachment-0001.htm>