RE: Memory Leaking with NetSNMP V5.5
> From: Mark Brooks [mailto:m...@loadbalancer.org] > Sent: Wednesday, April 28, 2010 1:27 PM > We are running the 2.6.32.7 kernel with Centos 5.3 and using the LVS > SNMP module http://kb.linuxvirtualserver.org/wiki/Net-SNMP-LVS-Module > the memory usage increases each time we use snmpwalk to poll the system, > and increases with each query until the box crashes. Has anyone else > come across this issue. Or could kindly push us in the right direction > as where to look next. Run snmpd without the dlmod for the LVS module and try the same test. If there is no memory leak, then the problem is with with the LVS module, and you'll have to get support from them. If not, let us know. HTH, Mike -- ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: Memory Leaking with NetSNMP V5.5
Firstly apologies for the length of this email all To further the game - we thing there is an issue with snmp and the lvs module. ive been using valgrind all afternoon with different options. I think I have narrowed it down to being to problem with specific MIBs. If i do an snmp walk snmpwalk -c public -v 2c 192.168.2.32 to get it to dump everything I get the following output from [r...@lbmaster sbin]# valgrind --tool=memcheck --leak-check=yes snmpd -f -Lo ==31959== Memcheck, a memory error detector. ==31959== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==31959== Using LibVEX rev 1658, a library for dynamic binary translation. ==31959== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==31959== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==31959== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==31959== For more details, rerun with: -v ==31959== ==31959== Warning: noted but unhandled ioctl 0x8946 with no size/direction hints ==31959==This could cause spurious value errors to appear. ==31959==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==31959== Warning: noted but unhandled ioctl 0x8946 with no size/direction hints ==31959==This could cause spurious value errors to appear. ==31959==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==31959== Warning: noted but unhandled ioctl 0x8946 with no size/direction hints ==31959==This could cause spurious value errors to appear. ==31959==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. IPVS initialization for duplicate registration (lvsNumServices, lvsNumServices)NET-SNMP version 5.5 ==31959== Invalid read of size 4 ==31959==at 0x4EDB8FE: tcpConnectionState_get (tcpConnectionTable.c:523) ==31959==by 0x4F0ACFF: _mfd_tcpConnectionTable_get_values (tcpConnectionTable_interface.c:885) ==31959==by 0x4C1FA97: _baby_steps_access_multiplexer (baby_steps.c:460) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C1FDB3: _baby_steps_helper (baby_steps.c:279) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C2C1C1: _container_table_handler (table_container.c:655) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C2888B: table_helper_handler (table.c:642) ==31959==by 0x3841A1D436: netsnmp_call_handlers (agent_handler.c:440) ==31959==by 0x3841A0DBAE: handle_var_requests (snmp_agent.c:2611) ==31959== Address 0x55C7DD4 is 44 bytes inside a block of size 64 free'd ==31959==at 0x4A0541E: free (vg_replace_malloc.c:233) ==31959==by 0x5247838: _ba_clear (container_binary_array.c:327) ==31959==by 0x4F06C59: netsnmp_access_tcpconn_container_free (container.h:475) ==31959==by 0x4F0B2B8: tcpConnectionTable_container_load (tcpConnectionTable_data_access.c:259) ==31959==by 0x4C207B3: _cache_load (cache_handler.c:570) ==31959==by 0x4C212EF: netsnmp_cache_helper_handler (cache_handler.c:512) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C2888B: table_helper_handler (table.c:642) ==31959==by 0x3841A1D436: netsnmp_call_handlers (agent_handler.c:440) ==31959==by 0x3841A0DBAE: handle_var_requests (snmp_agent.c:2611) ==31959==by 0x3841A0ECAF: handle_getnext_loop (snmp_agent.c:3051) ==31959==by 0x3841A11697: netsnmp_handle_request (snmp_agent.c:3203) ==31959== ==31959== Invalid read of size 4 ==31959==at 0x4EDB7CE: tcpConnectionProcess_get (tcpConnectionTable.c:580) ==31959==by 0x4F0AD90: _mfd_tcpConnectionTable_get_values (tcpConnectionTable_interface.c:895) ==31959==by 0x4C1FA97: _baby_steps_access_multiplexer (baby_steps.c:460) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C1FDB3: _baby_steps_helper (baby_steps.c:279) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C2C1C1: _container_table_handler (table_container.c:655) ==31959==by 0x3841A1DBCD: netsnmp_call_next_handler (agent_handler.c:440) ==31959==by 0x4C2888B: table_helper_handler (table.c:642) ==31959==by 0x3841A1D436: netsnmp_call_handlers (agent_handler.c:440) ==31959==by 0x3841A0DBAE: handle_var_requests (snmp_agent.c:2611) ==31959== Address 0x55C7DD8 is 48 bytes inside a block of size 64 free'd ==31959==at 0x4A0541E: free (vg_replace_malloc.c:233) ==31959==by 0x5247838: _ba_clear (container_binary_array.c:327) ==31959==by 0x4F06C59: netsnmp_access_tcpconn_container_free (container.h:475) ==31959==by 0x4F0B2B8: tcpConnectionTable_container_load (tcpConnectionTable_data_access.c:259) ==31959==by 0x4C207B3: _ca
Re: Memory Leaking with NetSNMP V5.5
Ok we have had a further revelation after much testing we were able to work out that there is one particular OID that is leaking 255 bytes of data each time you run snmpwalk the oid in particular is: .1.3.6.1.2.1.88.1.4.3.1.3.6.95.115.110.109.112.100.95.109.116.101.84.114.105.103.103.101.114.82.105.115.105.110.103 or its shorter name is DISMAN-EVENT-MIB::mteEventNotificationObjects."_snmpd".'_mteTriggerRising' the result of which is - DISMAN-EVENT-MIB::mteEventNotificationObjects."_snmpd".'_mteTriggerRising' = STRING: _triggerFire we can quite happily run snmpwalk above and below this OID and get consistent memory usage with no sign of a leak. What we cant quite work out is what function is failing to free the memory after its run. any help on how to debug this further would be much appreciated. Mark On 5 May 2010 16:17, Mark Brooks wrote: > > Mark >> >> >> >> >> On 29 April 2010 00:59, Mike Ayers wrote: >> >>> > From: Mark Brooks [mailto:m...@loadbalancer.org] >>> > Sent: Wednesday, April 28, 2010 1:27 PM >>> >>> > We are running the 2.6.32.7 kernel with Centos 5.3 and using the LVS >>> > SNMP module http://kb.linuxvirtualserver.org/wiki/Net-SNMP-LVS-Module >>> > the memory usage increases each time we use snmpwalk to poll the >>> system, >>> > and increases with each query until the box crashes. Has anyone else >>> > come across this issue. Or could kindly push us in the right direction >>> > as where to look next. >>> >>> Run snmpd without the dlmod for the LVS module and try the same >>> test. If there is no memory leak, then the problem is with with the LVS >>> module, and you'll have to get support from them. If not, let us know. >>> >>> >>>HTH, >>> >>> Mike >>> >>> >> > > -- ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: Memory Leaking with NetSNMP V5.5
Sorry I ment 225 bytes not 255 On 6 May 2010 13:59, Mark Brooks wrote: > Ok we have had a further revelation after much testing we were able to work > out that there is one particular OID that is leaking 255 bytes of data each > time you run snmpwalk the oid in particular is: > > .1.3.6.1.2.1.88.1.4.3.1.3.6.95.115.110.109.112.100.95.109.116.101.84.114.105.103.103.101.114.82.105.115.105.110.103 > or its shorter name is > DISMAN-EVENT-MIB::mteEventNotificationObjects."_snmpd".'_mteTriggerRising' > > the result of which is - > DISMAN-EVENT-MIB::mteEventNotificationObjects."_snmpd".'_mteTriggerRising' > = STRING: _triggerFire > > we can quite happily run snmpwalk above and below this OID and get > consistent memory usage with no sign of a leak. > > What we cant quite work out is what function is failing to free the memory > after its run. > > any help on how to debug this further would be much appreciated. > > Mark > > On 5 May 2010 16:17, Mark Brooks wrote: > >> >> Mark >>> >>> >>> >>> >>> On 29 April 2010 00:59, Mike Ayers wrote: >>> > From: Mark Brooks [mailto:m...@loadbalancer.org] > Sent: Wednesday, April 28, 2010 1:27 PM > We are running the 2.6.32.7 kernel with Centos 5.3 and using the LVS > SNMP module http://kb.linuxvirtualserver.org/wiki/Net-SNMP-LVS-Module > the memory usage increases each time we use snmpwalk to poll the system, > and increases with each query until the box crashes. Has anyone else > come across this issue. Or could kindly push us in the right direction > as where to look next. Run snmpd without the dlmod for the LVS module and try the same test. If there is no memory leak, then the problem is with with the LVS module, and you'll have to get support from them. If not, let us know. HTH, Mike >>> >> >> > -- ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
