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 Solutions
www.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 <[email protected]
<mailto:[email protected]>> 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 Solutions
www.opensips-solutions.com <http://www.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
<[email protected] <mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 Solutions
www.opensips-solutions.com
<http://www.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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
