#2063 *_release_rowreq_ctx leaks memory in several mibs

open
nobody
5
2012-11-08
2009-07-16
No

Version: 5.4.2.1 (+SUSE patches) on SLES11

Valgrind output:
==20263== 1,748 (1,104 direct, 644 indirect) bytes in 46 blocks are definitely lost in loss record 108 of 131
==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x1F63B5: netsnmp_file_create (file_utils.c:65)
==20263== by 0x1F6464: netsnmp_file_fill (file_utils.c:93)
==20263== by 0x19CFEE: netsnmp_arch_udp_endpoint_container_load (udp_endpoint_linux.c:256)
==20263== by 0x19CDE5: netsnmp_access_udp_endpoint_container_load (udp_endpoint_common.c:81)
==20263== by 0x19AF8B: udpEndpointTable_container_load (udpEndpointTable_data_access.c:238)
==20263== by 0xC7700: _cache_load (cache_handler.c:537)
==20263== by 0xC84C4: netsnmp_cache_helper_handler (cache_handler.c:477)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC9B88: table_helper_handler (table.c:619)
==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
==20263==
==20263==
==20263== 1,620 bytes in 45 blocks are definitely lost in loss record 111 of 131
==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x214F39: _ba_iterator_get (container_binary_array.c:717)
==20263== by 0xFF189: ipAddressPrefixTable_container_load (ipAddressPrefixTable_data_access.c:217)
==20263== by 0xC7700: _cache_load (cache_handler.c:537)
==20263== by 0xC84C4: netsnmp_cache_helper_handler (cache_handler.c:477)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC9B88: table_helper_handler (table.c:619)
==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
==20263== by 0x95477: handle_getnext_loop (snmp_agent.c:2982)
==20263== by 0x982B7: netsnmp_handle_request (snmp_agent.c:3134)
==20263== by 0x9878C: handle_snmp_packet (snmp_agent.c:1864)
==20263==
==20263==
==20263== 1,656 bytes in 46 blocks are definitely lost in loss record 112 of 131
==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x185424: netsnmp_access_arp_entry_create (arp_common.c:115)
==20263== by 0x185C94: _load_v4 (arp_linux.c:124)
==20263== by 0x186129: netsnmp_access_arp_container_arch_load (arp_linux.c:50)
==20263== by 0x1856F5: netsnmp_access_arp_container_load (arp_common.c:72)
==20263== by 0x167376: inetNetToMediaTable_container_load (inetNetToMediaTable_data_access.c:265)
==20263== by 0xC7700: _cache_load (cache_handler.c:537)
==20263== by 0xC84C4: netsnmp_cache_helper_handler (cache_handler.c:477)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC9B88: table_helper_handler (table.c:619)
==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
==20263==
==20263==
==20263== 1,840 bytes in 46 blocks are definitely lost in loss record 113 of 131
==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x14D4F6: netsnmp_access_defaultrouter_entry_create (defaultrouter_common.c:154)
==20263== by 0x14E3AC: netsnmp_arch_defaultrouter_container_load (defaultrouter_linux.c:285)
==20263== by 0x14DC25: netsnmp_access_defaultrouter_container_load (defaultrouter_common.c:106)
==20263== by 0xF783B: ipDefaultRouterTable_container_load (ipDefaultRouterTable_data_access.c:299)
==20263== by 0xC7700: _cache_load (cache_handler.c:537)
==20263== by 0xC84C4: netsnmp_cache_helper_handler (cache_handler.c:477)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC9B88: table_helper_handler (table.c:619)
==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
==20263== by 0x95477: handle_getnext_loop (snmp_agent.c:2982)
==20263==

The problem is roughly the same in all cases: rowreq_ctx contains user added
data which is not freed when releasing the rowreq_ctx, but the data is not
actually used anywhere else, so it is lost.
This is actually a bug in mfd-interface I guess, but I would have no idea
to express this there.

Note that some of these are not present in 5.4.2.1 but only in backports
from trunk done by SUSE.

Discussion

  • Hrm, sorry. Some of the valgrind traces above belong to other memleaks I report today ;).
    Here is another related one:

    ==20263==
    ==20263== 36,828 bytes in 837 blocks are definitely lost in loss record 125 of 131
    ==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
    ==20263== by 0x1A2AA6: netsnmp_access_tcpconn_entry_create (tcpConn_common.c:131)
    ==20263== by 0x1A33A4: netsnmp_arch_tcpconn_container_load (tcpConn_linux.c:174)
    ==20263== by 0x1A2D45: netsnmp_access_tcpconn_container_load (tcpConn_common.c:86)
    ==20263== by 0x1982E9: tcpListenerTable_container_load (tcpListenerTable_data_access.c:239)
    ==20263== by 0xC7700: _cache_load (cache_handler.c:537)
    ==20263== by 0xC84C4: netsnmp_cache_helper_handler (cache_handler.c:477)
    ==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
    ==20263== by 0xC9B88: table_helper_handler (table.c:619)
    ==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
    ==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
    ==20263== by 0x95477: handle_getnext_loop (snmp_agent.c:2982)
    ==20263==