Bug 518633 - snmpd leaks memory
snmpd leaks memory
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp (Show other bugs)
5.5
All Linux
urgent Severity medium
: rc
: ---
Assigned To: Jan Safranek
BaseOS QE
: ZStream
Depends On:
Blocks: 518920
  Show dependency treegraph
 
Reported: 2009-08-21 07:30 EDT by Michal Marciniszyn
Modified: 2014-02-10 18:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:29:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Valgrind output (4.74 KB, application/x-gzip)
2009-08-21 07:33 EDT, Michal Marciniszyn
no flags Details
valgrind log of snmpd from net-snmp-5.3.2.2-8.el5 (72.71 KB, application/octet-stream)
2010-01-08 09:39 EST, Karel Srot
no flags Details
valgrind log of snmpd from net-snmp-5.3.2.2-8.el5 on x86_64 (72.72 KB, text/plain)
2010-01-08 09:41 EST, Karel Srot
no flags Details

  None (edit)
Description Michal Marciniszyn 2009-08-21 07:30:59 EDT
Description of problem:
snmpd cyclically leaks memory


Version-Release number of selected component (if applicable):
net-snmp-5.3.2.2-7.el5_4.1

How reproducible:
Always

Steps to Reproduce:
1. run snmpd inside valgrind and try to walk over whole tree
2.
3.
  
Actual results:
There is memory leak in the valgrind output that is growing over the time.


Expected results:
No growing memory leaks.


Additional info:
See valgrind output in attachment.
Comment 1 Michal Marciniszyn 2009-08-21 07:33:25 EDT
Created attachment 358228 [details]
Valgrind output
Comment 3 Jan Safranek 2009-08-21 07:47:03 EDT
I have cure for leaks in ipAddressPrefixTable_container_load, ipv6ScopeZoneIndexTable_container_load, udpEndpointTable_container_load, ipDefaultRouterTable_container_load, ipIfStatsTable_container_load, udpEndpointTable_container_load and tcpListenerTable_container_load.

The others seem to occur only during initialization of the agent and do not grow in time.
Comment 7 Karel Srot 2010-01-08 09:39:07 EST
Created attachment 382479 [details]
valgrind log of snmpd from net-snmp-5.3.2.2-8.el5

Memory leaks are present also in net-snmp-5.3.2.2-8.el5. See the attachment for valgrind log of snmpd after cca 18 iterations of "snmpwalk -v 1 -c public localhost .1".

==9056== LEAK SUMMARY:
==9056==    definitely lost: 5,866 bytes in 47 blocks.
==9056==    indirectly lost: 80 bytes in 1 blocks.
==9056==      possibly lost: 3,496 bytes in 35 blocks.
==9056==    still reachable: 1,455,269 bytes in 24,094 blocks.
==9056==         suppressed: 0 bytes in 0 blocks.
Comment 8 Karel Srot 2010-01-08 09:41:07 EST
Created attachment 382480 [details]
valgrind log of snmpd from net-snmp-5.3.2.2-8.el5 on x86_64

Memory leaks are present also in net-snmp-5.3.2.2-8.el5. See the attachment for
valgrind log of snmpd after cca 70 iterations of "snmpwalk -v 1 -c public
localhost .1".
Comment 9 Jan Safranek 2010-01-11 10:00:41 EST
This one has been fixed upstream in SVN rev. #17795

==9158== 15,750 bytes in 70 blocks are definitely lost in loss record 166 of 186
 malloc (vg_replace_malloc.c:149)
 snmp_clone_mem (in /usr/lib64/libnetsnmp.so.10.0.3)
 netsnmp_table_build_oid_from_index (in /usr/lib64/libnetsnmphelpers.so.10.0.3)
 netsnmp_call_handler (in /usr/lib64/libnetsnmpagent.so.10.0.3)
 table_helper_handler (in /usr/lib64/libnetsnmphelpers.so.10.0.3)
...
Comment 10 Jan Safranek 2010-01-11 11:21:15 EST
This one remains mystery, I can't reproduce it locally:

9,472 bytes in 148 blocks are definitely lost in loss record 164 of 186
 calloc (vg_replace_malloc.c:279)
 net_snmp_create_prefix_info (in /usr/lib64/libnetsnmpmibs.so.10.0.3)
 netsnmp_prefix_listen (in /usr/lib64/libnetsnmpmibs.so.10.0.3)
 start_thread (in /lib64/libpthread-2.5.so)
 clone (in /lib64/libc-2.5.so)

Investigation continues....
Comment 11 Jan Safranek 2010-01-13 06:10:49 EST
(In reply to comment #10)
> This one remains mystery, I can't reproduce it locally:
> 
> 9,472 bytes in 148 blocks are definitely lost in loss record 164 of 186
>  calloc (vg_replace_malloc.c:279)
>  net_snmp_create_prefix_info (in /usr/lib64/libnetsnmpmibs.so.10.0.3)
>  netsnmp_prefix_listen (in /usr/lib64/libnetsnmpmibs.so.10.0.3)
>  start_thread (in /lib64/libpthread-2.5.so)
>  clone (in /lib64/libc-2.5.so)
> 

Finally I am able to reproduce it - snmpd receives information about incoming ICMPv6 router advertisements from kernel (via netlink) and it sometimes leaks memory during its processing. Therefore, you just need to find a machine on network segment, which is handled by IPv6 router - our lab network seems to be fine. Check, that the machine under test periodically (~each minute) receives ICMPv6 router advertisement (tshark ip6) and let snmpd running for few minutes to process several such messages. The leak appears in valgrind output then.
Comment 14 Justin Lintz 2010-03-04 11:39:03 EST
I'm seeing a leak as well in the udpEndpointTable (.1.3.6.1.2.1.7.7) , walking it consistently grows the number of file descriptors.  I found a patch at http://sourceforge.net/tracker/index.php?func=detail&aid=2822355&group_id=12694&atid=112694
Comment 15 Jan Safranek 2010-03-05 03:50:28 EST
(In reply to comment #14)
> I'm seeing a leak as well in the udpEndpointTable (.1.3.6.1.2.1.7.7) , walking
> it consistently grows the number of file descriptors.  I found a patch at
> http://sourceforge.net/tracker/index.php?func=detail&aid=2822355&group_id=12694&atid=112694    

I believe I've fixed this leak too. You can look forward to RHEL 5.5.
Comment 17 errata-xmlrpc 2010-03-30 04:29:04 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0253.html

Note You need to log in before you can comment on or make changes to this bug.