Menu
▾
▴
[ net-snmp-Bugs-2822358 ] udpEndpointTable memory leak
|
From: SourceForge.net <no...@so...> - 2009-07-16 09:43:08
|
Bugs item #2822358, was opened at 2009-07-16 11:43 Message generated for change (Tracker Item Submitted) made by djpig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2822358&group_id=12694 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mibs Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Lichtenheld (djpig) Assigned to: Nobody/Anonymous (nobody) Summary: udpEndpointTable memory leak Initial Comment: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2822358&group_id=12694 |