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 <[email protected] > 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 <[email protected]> > 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 <[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 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 < >>> <[email protected]>[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]>[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]>[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]>[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 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 < >>>>>>> <[email protected]>[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 >>> >>> >> >> >> _______________________________________________ >> Users mailing >> [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
