NSCA memory leak

[daniel at zoltak.com]

Hi list,

I am running nagios on Gentoo and having an issue with NSCA.

When NSCA is running for a few days I get it crashes with this in dmesg:

localhost nsca[6030]: segfault at ffffffffff600429 ip 00007f8d3ea19dfc sp
00007fff47281350 error 7 in libwrap.so.0.7.6[7f8d3ea16000+8000]

I compiled NSCA in debug mode and ran it with valgrind. We found the  
following memory
leak:

==8837== Syscall param fcntl(arg) contains uninitialised byte(s)
==8837==    at 0x553EF5B: fcntl (in /lib64/libc-2.9.so)
==8837==    by 0x402FE1: handle_connection (in /usr/bin/nsca)
==8837==    by 0x403369: accept_connection (in /usr/bin/nsca)
==8837==    by 0x4040D5: main (in /usr/bin/nsca)
==8840==
==8840== Syscall param fcntl(arg) contains uninitialised byte(s)
==8840==    at 0x553EF5B: fcntl (in /lib64/libc-2.9.so)
==8840==    by 0x402FE1: handle_connection (in /usr/bin/nsca)
==8840==    by 0x403369: accept_connection (in /usr/bin/nsca)
==8840==    by 0x4040D5: main (in /usr/bin/nsca)
==8842==
==8842== Syscall param fcntl(arg) contains uninitialised byte(s)
==8842==    at 0x553EF5B: fcntl (in /lib64/libc-2.9.so)
==8842==    by 0x402FE1: handle_connection (in /usr/bin/nsca)
==8842==    by 0x403369: accept_connection (in /usr/bin/nsca)
==8842==    by 0x4040D5: main (in /usr/bin/nsca)
==8838==
==8838== Syscall param fcntl(arg) contains uninitialised byte(s)
==8838==    at 0x553EF5B: fcntl (in /lib64/libc-2.9.so)
==8838==    by 0x402FE1: handle_connection (in /usr/bin/nsca)
==8838==    by 0x403369: accept_connection (in /usr/bin/nsca)
==8838==    by 0x4040D5: main (in /usr/bin/nsca)
==8828==
==8828== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 14 from 2)
==8828== malloc/free: in use at exit: 621 bytes in 25 blocks.
==8828== malloc/free: 115 allocs, 90 frees, 32,290 bytes allocated.
==8828== For counts of detected errors, rerun with: -v
==8828== Use --track-origins=yes to see where uninitialised values come from
==8828== searching for pointers to 25 not-freed blocks.
==8828== checked 124,080 bytes.
==8828==
==8828== LEAK SUMMARY:
==8828==    definitely lost: 584 bytes in 22 blocks.
==8828==      possibly lost: 0 bytes in 0 blocks.
==8828==    still reachable: 37 bytes in 3 blocks.
==8828==         suppressed: 0 bytes in 0 blocks.
==8828== Rerun with --leak-check=full to see details of leaked memory.

I then ran with options --leak-check=full --show-reachable=yes:

==21927== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 2)
==21927== malloc/free: in use at exit: 621 bytes in 25 blocks.
==21927== malloc/free: 96 allocs, 71 frees, 21,932 bytes allocated.
==21927== For counts of detected errors, rerun with: -v
==21927== Use --track-origins=yes to see where uninitialised values come from
==21927== searching for pointers to 25 not-freed blocks.
==21927== checked 122,080 bytes.
==21927==
==21927==
==21927== 37 bytes in 3 blocks are still reachable in loss record 1 of 4
==21927==    at 0x4C24C1E: malloc (in  
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21927==    by 0x54F5D31: strdup (in /lib64/libc-2.9.so)
==21927==    by 0x402B6C: read_config_file (in /usr/bin/nsca)
==21927==    by 0x4037DD: main (in /usr/bin/nsca)
==21927==
==21927==
==21927== 584 (104 direct, 480 indirect) bytes in 2 blocks are  
definitely lost in loss record 2 of 4
==21927==    at 0x4C24C1E: malloc (in  
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21927==    by 0x555A4AA: (within /lib64/libc-2.9.so)
==21927==    by 0x555AC26: __nss_database_lookup (in /lib64/libc-2.9.so)
==21927==    by 0x5BD233F: ???
==21927==    by 0x5BD33D6: ???
==21927==    by 0x5519EA2: getpwnam_r (in /lib64/libc-2.9.so)
==21927==    by 0x551985F: getpwnam (in /lib64/libc-2.9.so)
==21927==    by 0x403ADE: main (in /usr/bin/nsca)
==21927==
==21927==
==21927== 160 bytes in 10 blocks are indirectly lost in loss record 3 of 4
==21927==    at 0x4C24C1E: malloc (in  
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21927==    by 0x555A079: __nss_lookup_function (in /lib64/libc-2.9.so)
==21927==    by 0x5BD235A: ???
==21927==    by 0x5BD33D6: ???
==21927==    by 0x5519EA2: getpwnam_r (in /lib64/libc-2.9.so)
==21927==    by 0x551985F: getpwnam (in /lib64/libc-2.9.so)
==21927==    by 0x403ADE: main (in /usr/bin/nsca)
==21927==
==21927==
==21927== 320 bytes in 10 blocks are indirectly lost in loss record 4 of 4
==21927==    at 0x4C24C1E: malloc (in  
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21927==    by 0x5549D90: tsearch (in /lib64/libc-2.9.so)
==21927==    by 0x555A019: __nss_lookup_function (in /lib64/libc-2.9.so)
==21927==    by 0x5BD235A: ???
==21927==    by 0x5BD33D6: ???
==21927==    by 0x5519EA2: getpwnam_r (in /lib64/libc-2.9.so)
==21927==    by 0x551985F: getpwnam (in /lib64/libc-2.9.so)
==21927==    by 0x403ADE: main (in /usr/bin/nsca)
==21927==
==21927== LEAK SUMMARY:
==21927==    definitely lost: 104 bytes in 2 blocks.
==21927==    indirectly lost: 480 bytes in 20 blocks.
==21927==      possibly lost: 0 bytes in 0 blocks.
==21927==    still reachable: 37 bytes in 3 blocks.
==21927==         suppressed: 0 bytes in 0 blocks.

The versin of Gentoo runs libc 2.9. We have a few Fedora core 8  
machines running libc 2.7
with the same version of NSCA but don't see the issue.

Can anyone shead some light on the issue. Is it a NSCA issue or  
libc/Gentoo issue?

Thanks


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry