Hi, Mickael!

Can you check if there are also any transactions hanged? Also, What is the scenario you are using? When are you populating these variables?

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 07/09/2015 12:17 PM, Mickael Marrache wrote:
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 <[email protected] <mailto:[email protected]>> 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 Solutions
    www.opensips-solutions.com <http://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] <mailto:[email protected]>
    http://lists.opensips.org/cgi-bin/mailman/listinfo/users


    _______________________________________________
    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

Reply via email to