[OpenSIPS-Users] Possible memory leak related to AVPs

[Mickael Marrache]

Hi Razvan,

I'm using GDB as follows:

(gdb) p get_avp_name_id(((struct usr_avp*)0x2ba445441948)->id)

Program received signal SIGUSR2, User defined signal 2.
get_avp_name_id (id=139) at usr_avp.c:263
263     {
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (get_avp_name_id) will
be abandoned.

where ((struct usr_avp*)0x2ba445441948)->id gives me the AVP id.

I expect the result to be of type str* (representing the AVP name) but it
looks like some signal is received while executing the function.

Any idea?

Thanks,
Mickael

On Tue, Jun 23, 2015 at 12:08 PM, Răzvan Crainea <razvan at opensips.org>
wrote:

>  Hi, Mickael!
>
> That's the correct usage, and the AVP is attached to the transaction, and
> destroyed when the transaction is destroyed. However, it depends on the
> context when the AVP is populated. Is it done for each message? Timer based?
> If I were you, I'd continue tracing the name of the AVPs and checking
> where they are populated.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 06/22/2015 07:28 PM, Mickael Marrache wrote:
>
> 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>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>
>> 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>
>>> 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
>>>>
>>>>
> _______________________________________________
> 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/20150623/f287beed/attachment.htm>