[OpenSIPS-Users] Possible memory leak related to AVPs

Mickael Marrache mickaelmarrache at gmail.com
Thu Jun 18 20:56:08 CEST 2015


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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150618/61e75362/attachment-0001.htm>


More information about the Users mailing list