NSCA memory leak

[Andreas Ericsson]

daniel at zoltak.com wrote:
> 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?
> 

If you're seeing it with one version of libc but not with another, it's
probably due to either libc or the compiler, or a combination of the two.
Have you tried recompiling from source? Does it show the same leak?

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
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