NSCA memory leak

daniel at zoltak.com daniel at zoltak.com
Tue Jul 7 03:37:30 CEST 2009


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. The  
results are attached (20090707_valgrind_full_options.txt).

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
-------------- next part --------------
==21925== Memcheck, a memory error detector.
==21925== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==21925== Using LibVEX rev 1878, a library for dynamic binary translation.
==21925== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==21925== Using valgrind-3.4.0, a dynamic binary instrumentation framework.
==21925== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==21925== For more details, rerun with: -v
==21925==
==21925== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==21925==    at 0x54AD394: (within /lib64/libc-2.9.so)
==21925==    by 0x403A07: main (in /usr/bin/nsca)
==21925==  Address 0x7fefff998 is on thread 1's stack
==21925==
==21925== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1)
==21925== malloc/free: in use at exit: 37 bytes in 3 blocks.
==21925== malloc/free: 4 allocs, 1 frees, 605 bytes allocated.
==21925== For counts of detected errors, rerun with: -v
==21925== Use --track-origins=yes to see where uninitialised values come from
==21925== searching for pointers to 3 not-freed blocks.
==21925== checked 122,192 bytes.
==21925==
==21925==
==21925== 37 bytes in 3 blocks are still reachable in loss record 1 of 1
==21925==    at 0x4C24C1E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21925==    by 0x54F5D31: strdup (in /lib64/libc-2.9.so)
==21925==    by 0x402B6C: read_config_file (in /usr/bin/nsca)
==21925==    by 0x4037DD: main (in /usr/bin/nsca)
==21925==
==21925== LEAK SUMMARY:
==21925==    definitely lost: 0 bytes in 0 blocks.
==21925==      possibly lost: 0 bytes in 0 blocks.
==21925==    still reachable: 37 bytes in 3 blocks.
==21925==         suppressed: 0 bytes in 0 blocks.
==21927==
==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.
-------------- next part --------------
------------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list