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
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]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
