Hi Robert, Thanks for the reply. Please find below the valgrind report for the growing leak : a) Below report when snmp is up and running :
255 (108 direct, 147 indirect) bytes in 3 blocks are definitely lost in loss record 105 of 153 ==20680== at 0x4004864: calloc (vg_replace_malloc.c:279) ==20680== by 0x83E761C: netsnmp_access_ipaddress_entry_create (ipaddress_common.c:175) ==20680== by 0x84BEEFA: _netsnmp_ioctl_ipaddress_container_load_v4 (ipaddress_ioctl.c:174) ==20680== by 0x84BE444: netsnmp_arch_ipaddress_container_load (ipaddress_linux.c:149) ==20680== by 0x83E750A: netsnmp_access_ipaddress_container_load (ipaddress_common.c:120) ==20680== by 0x84BDA70: ipAddressTable_container_load (ipAddressTable_data_access.c:345) ==20680== by 0x84BD370: _cache_load (ipAddressTable_interface.c:1922) ==20680== by 0x84CC524: _cache_load (cache_handler.c:548) ==20680== by 0x84CBDED: _timer_reload (cache_handler.c:197) ==20680== by 0x84E86D2: run_alarms (snmp_alarm.c:266) ==20680== by 0x83BFF7F: receive (snmpd.c:1504) ==20680== by 0x83BF3A4: snmpd (snmpd.c:1177) b) Below report when i left snmp running for more than one hour: 10,200 (4,320 direct, 5,880 indirect) bytes in 120 blocks are definitely lost in loss record 136 of 154 ==20742== at 0x4004864: calloc (vg_replace_malloc.c:279) ==20742== by 0x83E761C: netsnmp_access_ipaddress_entry_create (ipaddress_common.c:175) ==20742== by 0x84BEEFA: _netsnmp_ioctl_ipaddress_container_load_v4 (ipaddress_ioctl.c:174) ==20742== by 0x84BE444: netsnmp_arch_ipaddress_container_load (ipaddress_linux.c:149) ==20742== by 0x83E750A: netsnmp_access_ipaddress_container_load (ipaddress_common.c:120) ==20742== by 0x84BDA70: ipAddressTable_container_load (ipAddressTable_data_access.c:345) ==20742== by 0x84BD370: _cache_load (ipAddressTable_interface.c:1922) ==20742== by 0x84CC524: _cache_load (cache_handler.c:548) ==20742== by 0x84CBDED: _timer_reload (cache_handler.c:197) ==20742== by 0x84E86D2: run_alarms (snmp_alarm.c:266) ==20742== by 0x83BFF7F: receive (snmpd.c:1504) ==20742== by 0x83BF3A4: snmpd (snmpd.c:1177) You can see that Leak ( definitely lost memory ) is increased from 255 to 10,200 bytes. Why the run_alarms function calls the function to load the container always if it already has been done once. I am new to the container concept, please give me some pointers to work with this issue. Regards, Manjit Robert Story wrote: > On Fri, 07 May 2010 17:36:18 +0530 Manjit wrote: > M> ==698== by 0x84BD990: ipAddressTable_container_load > M> Please provide me information for the below queries : > M> 1. what is the purpose of run_alarms() ? > > Just what is says... It runs alarms, or events. > > M> 2. How the system will be affected if i will not call (or comment ) > M> function ? > > It's possible that lots of things depending on alarms to be run at regular > intervals will break. The problem is not with run_alarms itself, but with the > particular alarm being run. Try running with -I-ipAddressTable to disable the > ipAddressTableand it's alarm, though I suspect it's being called via ifTable. > > I'm also not sure memory is being lost. Are you actually seeing the memory > leak growing? Lots of places in net-snmp allocate memory that isn't explicitly > released when shutting down, but they don't cause growing leaks during > runtime. > > ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
