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 Solutions
www.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 <[email protected]
<mailto:[email protected]>> 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 Solutions
www.opensips-solutions.com <http://www.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
<[email protected] <mailto:[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] <mailto:[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 Solutions
www.opensips-solutions.com
<http://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>
_______________________________________________
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
