Hi Robert/All, The issue was because of some changes made by myself as per my requirements. So there is not such leak. Sorry for this.
Robert, as you said that netsnmp allocates memory that isn't explicitly removed until shutdown. What happens when the snmpd goes for a reconfig not shutdown. Please let me know your comment on this. Regards, Manjit Manjit wrote: > 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 > > ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
