Menu

#2674 [FreeBSD][patch] Memory leak in 5.7.3

freeBSD
closed
None
5
2016-08-31
2015-10-13
No

Laurent GOUHIER lg@efficientip.com reported multiple memory leaks in net-snmp, discovered via valgrind. I've attached his patch that resolves a pair of memory leaks, although it seems like there are others.

The following is his report to me:

They are some other leaks here an extract from valgrind:

==36349== 18,019,488 bytes in 48,966 blocks are definitely lost in loss
record 601 of 601

==36349== at 0x4C23C90: calloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==36349== by 0x510A096: netsnmp_swrun_entry_create (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x51182EF: netsnmp_arch_swrun_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x5109CA0: netsnmp_swrun_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x5109B81: _cache_load (in /tmp/libnetsnmpmibs.so.30)
==36349== by 0x4E402DE: _cache_load (in /tmp/libnetsnmpagent.so.30)
==36349== by 0x5109A75: swrun_count_processes (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x50C6258: var_hrsys (in /tmp/libnetsnmpmibs.so.30)
==36349== by 0x4E433A8: netsnmp_old_api_helper (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E3F7DF: netsnmp_bulk_to_next_helper (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)

==36349== 2,313,343 (1,740,312 direct, 573,031 indirect) bytes in 1,151
blocks are definitely lost in loss record 597 of 601

==36349== at 0x4C23C90: calloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==36349== by 0x65A1B8B: pkg_new (in /usr/local/lib/libpkg.so.3.0.0)
==36349== by 0x65EE4A6: pkgdb_it_next (in /usr/local/lib/libpkg.so.3.0.0)
==36349== by 0x5118001: netsnmp_swinst_arch_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x5109330: netsnmp_swinst_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x50C5C56: _cache_load (in /tmp/libnetsnmpmibs.so.30)
==36349== by 0x4E402DE: _cache_load (in /tmp/libnetsnmpagent.so.30)
==36349== by 0x4E40201: netsnmp_cache_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E479F3: table_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E3F7DF: netsnmp_bulk_to_next_helper (in
/tmp/libnetsnmpagent.so.30)

==36349== 1,698,575 (13,472 direct, 1,685,103 indirect) bytes in 842
blocks are definitely lost in loss record 595 of 601

==36349== at 0x4C23C90: calloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==36349== by 0x550CED8: ??? (in /tmp/libnetsnmp.so.30)
==36349== by 0x550954A: CONTAINER_INSERT_HELPER (in
/tmp/libnetsnmp.so.30)
==36349== by 0x5167A5B: _load_routing_table_from_sysctl (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x516741B: netsnmp_access_route_container_arch_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x5166E81: netsnmp_access_route_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x515B0C8: inetCidrRouteTable_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x4E402DE: _cache_load (in /tmp/libnetsnmpagent.so.30)
==36349== by 0x4E40201: netsnmp_cache_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E41D90: netsnmp_instance_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)

==36349== 3,277,400 (174,464 direct, 3,102,936 indirect) bytes in 1,363
blocks are definitely lost in loss record 599 of 601

==36349== at 0x4C226C0: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==36349== by 0x65FE823: ??? (in /usr/local/lib/libpkg.so.3.0.0)
==36349== by 0x65B689E: ??? (in /usr/local/lib/libpkg.so.3.0.0)
==36349== by 0x65B5EA1: pkg_ini (in /usr/local/lib/libpkg.so.3.0.0)
==36349== by 0x5117E13: netsnmp_swinst_arch_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x5109330: netsnmp_swinst_container_load (in
/tmp/libnetsnmpmibs.so.30)
==36349== by 0x50C5C56: _cache_load (in /tmp/libnetsnmpmibs.so.30)
==36349== by 0x4E402DE: _cache_load (in /tmp/libnetsnmpagent.so.30)
==36349== by 0x4E40201: netsnmp_cache_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E479F3: table_helper_handler (in
/tmp/libnetsnmpagent.so.30)
==36349== by 0x4E531BF: netsnmp_call_handler (in
/tmp/libnetsnmpagent.so.30)

==36349== LEAK SUMMARY:
==36349== definitely lost: 27,702,767 bytes in 395,673 blocks
==36349== indirectly lost: 13,062,014 bytes in 293,185 blocks
==36349== possibly lost: 88,041 bytes in 1,336 blocks
==36349== still reachable: 294,448 bytes in 919 blocks
==36349== suppressed: 0 bytes in 0 blocks

If you want you can found the script i used for my test bellow :

[lg@vmdev-lg ~]$ cat /tmp/snmpdtest.sh

!/bin/sh

sleep in bash for loop

a=1
b=1
date >> snmpdtest.log
echo "BEGIN to send queris..." >> snmpdtest.log
while [ $b -lt 50 ]; do
echo "Loop $a.$b" >> snmpdtest.log
ps aux | grep 'snmpd' | awk '{print $5, $6}' >> snmpdtest.log
while [ $a -lt 100 ]; do
echo $a
snmpbulkwalk -On -v 2c -c public 127.0.0.1 .1 > /dev/null
snmpwalk -On -v 2c -c public 127.0.0.1 .1 > /dev/null
a=expr $a + 1
done
b=expr $b + 1
a=1
done
date >> snmpdtest.log
echo "END sending queris..." >> snmpdtest.log

a=1
while [ $a -lt 1000 ]; do
ps aux | grep '[s]bin/snmpd' | awk '{print $5, $6}' >> snmpdtest.log
a=expr $a + 1
sleep 60
done

1 Attachments

Discussion

  • Niels Baggesen

    Niels Baggesen - 2015-11-24

    Thank for the patch! It has been applied for 5.7 and master

     
  • Niels Baggesen

    Niels Baggesen - 2015-11-24
    • status: open --> closed
    • assigned_to: Niels Baggesen
     
  • Marc Branchaud

    Marc Branchaud - 2016-07-07

    This fix seems to have been lost on the road to 5.7.

     
  • Niels Baggesen

    Niels Baggesen - 2016-08-31

    It is in 5.7.patches, I dont see what you mean?

     
  • Marc Branchaud

    Marc Branchaud - 2016-08-31

    Sorry, I was confused!

     

Log in to post a comment.