Date: Wed, 27 Jan 2010 23:01:04 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: Brandon Falk <falkman@gamozo.org> Cc: "'freebsd-hackers@freebsd.org'" <freebsd-hackers@freebsd.org> Subject: Re: Leaks in libc? Message-ID: <4B613630.6090307@freebsd.org> In-Reply-To: <4B604B43.7010203@gamozo.org> References: <4B604B43.7010203@gamozo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brandon Falk wrote: > The simple program: > > int main() > { > puts("Apple cider"); > > Yields the following result in valgrind: > > ==4703== HEAP SUMMARY: > ==4703== in use at exit: 4,096 bytes in 1 blocks > ==4703== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated > ==4703== > ==4703== suppressed: 4,096 bytes in 1 blocks > > Any ideas why the standard libraries are leaking like this? Is it > perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so > they took the cleanup out of their libc? This particular leak is not at all a cause for concern. Many parts of the system libraries use malloc() to allocate working memory that they deliberately never free. In this particular case, you're seeing a 4096-byte buffer that the stdio system allocates the first time you use it. If you use valgrind a lot, you'll soon learn to just ignore this and several other standard "memory leaks." Generally, memory leaks are a cause for concern only when they accumulate over time. This usually happens only when you have code that leaks memory every time it is used (this particular example doesn't qualify since this buffer is only allocated once regardless of how many times you use the stdio calls) and that code is then used in a very long-running program (such as a window manager or web server). Cheers, Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B613630.6090307>