RE: Memory leak in inetCidrRouteTable 5.7.3

Peilong Xia <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
Hi Soubhagya,

Please see function netsnmp_access_route_container_free(), it’s called by
inetCidrRouteTable_container_load().



Peilong





*From:* Soubhagya Panigrahi [mailto:[email protected]]
*Sent:* 2016年11月7日 21:56
*To:* [email protected];
[email protected]
*Subject:* Memory leak in inetCidrRouteTable 5.7.3



Hi All,

I have some queries with respect to memory leak in inetCidrRouteTable while
continuous query to inetCidrRouteTable .

Valgrind report
===============

7480 ==16547== 7,569,856 bytes in 3,416 blocks are definitely lost in loss
record 5,344 of 5,344
7481 ==16547==    at 0x4C266B0: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
7482 ==16547==    by 0x475E04: inetCidrRouteTable_allocate_rowreq_ctx
(snmp/subagent/inetCidrRouteTable_interface.c:584)
7483 ==16547==    by 0x47427A: add_ipv6_route_entries
(snmp/subagent/inetCidrRouteTable_data_access.c:792)
7484 ==16547==    by 0x474856: inetCidrRouteTable_container_load
(snmp/subagent/inetCidrRouteTable_data_access.c:693)
7485 ==16547==    by 0x52B83F4: _cache_load (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7486 ==16547==    by 0x52B8F9C: netsnmp_cache_helper_handler (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7487 ==16547==    by 0x52CC2F6: netsnmp_call_handler (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7488 ==16547==    by 0x52C048C: table_helper_handler (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7489 ==16547==    by 0x52CD25E: netsnmp_call_handlers (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7490 ==16547==    by 0x52D6880: handle_var_requests (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7491 ==16547==    by 0x52D7ABF: handle_getnext_loop (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7492 ==16547==    by 0x52DA8FF: netsnmp_handle_request (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7493 ==16547==    by 0x52DB3D9: handle_snmp_packet (in
/sw/linuxapps/usr/lib64/libnetsnmpagent.so.30.0.3)
7494 ==16547==    by 0x574A217: ??? (in
/sw/linuxapps/usr/lib64/libnetsnmp.so.30.0.3)
7495 ==16547==    by 0x574ABF6: _sess_read (in
/sw/linuxapps/usr/lib64/libnetsnmp.so.30.0.3)
7496 ==16547==    by 0x574BA38: snmp_sess_read2 (in
/sw/linuxapps/usr/lib64/libnetsnmp.so.30.0.3)
7497 ==16547==    by 0x574BAFA: snmp_read2 (in
/sw/linuxapps/usr/lib64/libnetsnmp.so.30.0.3)
7498 ==16547==    by 0x574BB43: snmp_read (in
/sw/linuxapps/usr/lib64/libnetsnmp.so.30.0.3)
7499 ==16547==    by 0x430C7A: agent_check_and_process_mutex
(snmp/subagent/cwoAoStatsTable_subag

As part of my project, we have added a support for ipv6 route entry in
"add_ipv6_route_entries()" under inetCidrRouteTable_container_load().

Allocating memory is same, how it is being done in
"inetCidrRouteTable_container_load()". But as per valgrind report, Leak is
showing in newly implemented add_ipv6_route_entries() code not in
inetCidrRouteTable_container_load(). So it is obvious that memory
deallocation part is not being implemenetd properly.

here my question is where and how to free the newly allocated memory . The
reason why I am asking in this forum is whether to call release request or
need to check how can i use CONTAINER_FREE for this.

I could see, for inetCidrRouteTable_container_load, there is one respective
"inetCidrRouteTable_release_rowreq_ctx(rowreq_ctx)" to free the memory
called by _cache_free() which is allocated through  _cache_load().

For reference pasting end part of my code snipet for both
inetCidrRouteTable_container_load() and add_ipv6_route_entries()
respectively. As you can see, rowreq_ctx is passed to CONTAINER_INSERT and
i hope it's being freed properly. But Inside add_ipv6_route_entries(), we
are again allocating memory for "rowreq_ctx" and again passing it to
CONTAINER_INSERT in same way. So here which one i need to take care of ??
Whether I need to free the container or need to release memory by calling
inetCidrRouteTable_release_rowreq_ctx().?


----------------------------------------------------------------------
inetCidrRouteTable_container_load (netsnmp_container *container)
...
...
    for (i = 0; i < route_table.no_entries; i++) {
...
...

    CONTAINER_INSERT(container, rowreq_ctx);
    ++count;
    }
    status = add_ipv6_route_entries(container, &count);


DEBUGMSGT(("verbose:inetCidrRouteTable:inetCidrRouteTable_container_load",
           "inserted %d records\n", (int) count));

    return status;
}                /* end of inetCidrRouteTable_container_load */
----------------------------------------------------------------------
add_ipv6_route_entries (netsnmp_container *container, size_t *count)
{
...
...
    for (i = 0; i < route_table6.no_entries; i++) {
...
...
    /*
     * insert into table container
     */
    CONTAINER_INSERT(container, rowreq_ctx);
    ++*count;
    }
    return MFD_SUCCESS;
}                /* end of add_ipv6_route_entries */

----------------------------------------------------------------------

It would be great if someone can explain what is the use of container here
and how it is used to insert and delete/free . whether it is being
maintained in background everytime or only at the time of query.
For above case what could be done to get rid of this issue.

-- 

*Regards*,
Soubhagya

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.