#2065 udpEndpointTable memory leak

[Frank Lichtenheld]

Version: 5.4.2.1 (+SUSE patches) on SLES11

Valgrind output:
==20263== 22,080 bytes in 552 blocks are definitely lost in loss record 123 of 131
==20263== at 0x482064B: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x1F1653: _pm_user_function (text_utils.c:364)
==20263== by 0x1F1B50: netsnmp_file_text_parse (text_utils.c:130)
==20263== by 0x19D03C: netsnmp_arch_udp_endpoint_container_load (udp_endpoint_linux.c:265)
==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==

The problem here is that the container_load function calls netsnmp_access_udp_endpoint_container_free with
NETSNMP_ACCESS_UDP_ENDPOINT_FREE_DONT_CLEAR. While this is correct in many mibs since the objects
in the container are usually loaded into the rowreq_ctx container, this is not the case here. Data from the objects is
put into other objects, but not the objects themself. So they should be cleaned up.

[Frank Lichtenheld]

Patch

[Dave Shield]

Thanks for the bug report!
We've fixed the problem in the 5.3.x and 5.4.x
code branches and the main development tree,
so it should be fixed in future releases of the
Net-SNMP package.

[Dave Shield]

jsafranek has recently applied the same patch - SVN revisions 17719