Bug 518633 - snmpd leaks memory
Summary: snmpd leaks memory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp
Version: 5.5
Hardware: All
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 518920
TreeView+ depends on / blocked
 
Reported: 2009-08-21 11:30 UTC by Michal Marciniszyn
Modified: 2014-02-10 23:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 08:29:04 UTC


Attachments (Terms of Use)
Valgrind output (4.74 KB, application/x-gzip)
2009-08-21 11:33 UTC, 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 14:39 UTC, 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 14:41 UTC, Karel Srot
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0253 normal SHIPPED_LIVE net-snmp bug fix and enhancement update 2010-03-29 12:46:44 UTC

Description Michal Marciniszyn 2009-08-21 11:30:59 UTC
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 11:33:25 UTC
Created attachment 358228 [details]
Valgrind output

Comment 3 Jan Safranek 2009-08-21 11:47:03 UTC
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 14:39:07 UTC
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 14:41:07 UTC
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 15:00:41 UTC
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 16:21:15 UTC
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 11:10:49 UTC
(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 16:39:03 UTC
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 08:50:28 UTC
(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 08:29:04 UTC
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.