[OpenSIPS-Users] Possible memory leak related to AVPs
Mickael Marrache
mickaelmarrache at gmail.com
Thu Jul 9 11:17:21 CEST 2015
Hi Razvan,
I have some news.
The suspects are not regular AVPs but branch AVPs that I set in a module.
Is there a specific handling for those AVPs?
Here is how I use it:
static str bavp_msgops_flags = str_init("$bavp(_msgops_bflags)");
pv_spec_t bavp_msgops_flags_spec;
In mod_init:
if (parse_store_bavp(&bavp_msgops_flags, &bavp_msgops_flags_spec)) {
LM_ERR("Fail to parse branch AVPs.\n");
return -1;
}
In a command called from branch_route:
b_flags.flags = PV_VAL_INT|PV_TYPE_INT;
b_flags.ri = 0;
if(pv_set_value(msg, &bavp_msgops_flags_spec, (int)EQ_T, &b_flags) != 0) {
LM_ERR("Fail to set branch flags AVP.\n");
return -1;
}
Sometimes, I do the following to get the branch AVP value:
if (pv_get_spec_value(rpl, &bavp_msgops_flags_spec, &b_flags_val) != 0) {
LM_ERR("Branch AVP not found!\n");
return;
}
Thanks,
Mickael
On Thu, Jul 2, 2015 at 2:34 PM, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Mickael!
>
> Not sure why the signal is triggered. But what you could do is to
> replicate the behavior of the function until you find the proper id.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 06/23/2015 05:37 PM, Mickael Marrache wrote:
>
> 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
>>
>>
>
>
> _______________________________________________
> 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/20150709/b6c95279/attachment-0001.htm>
More information about the Users
mailing list