From owner-freebsd-stable@FreeBSD.ORG Fri Mar 16 16:51:58 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E364D106566B for ; Fri, 16 Mar 2012 16:51:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE6D8FC15 for ; Fri, 16 Mar 2012 16:51:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9d3b:2123:5b75:85ad] (unknown [IPv6:2001:7b8:3a7:0:9d3b:2123:5b75:85ad]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E4295C37; Fri, 16 Mar 2012 17:51:56 +0100 (CET) Message-ID: <4F636FB0.3090305@FreeBSD.org> Date: Fri, 16 Mar 2012 17:52:00 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Ina J." References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 9.0: Valgrind leaks memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:51:59 -0000 On 2012-03-16 12:23, Ina J. wrote: ... > I've been developing program for Linux under Ubuntu 10.04. I want to get > the code running under my FreeBSD 9.0-RELEASE server. The code compiles > without problems, but Valgrind doesn't work the same way as on my Ubuntu. I > made an example code, which produces a memory leak with Valgrind. The code > is as follows: > > ### C O D E ### > #include > int main() > { > std::cout << "Valgrind leaks memory" << std::endl; > return 0; > } This also the case on -CURRENT, and it is because stdio allocates an output buffer for stdout, and doesn't free it at exit() time. Using C++ is not even necessary, if you use the following C program, the same occurs: $ cat test-stdio-leak.c #include int main(void) { puts("Leaky!"); return 0; } $ valgrind --show-reachable=yes --tool=memcheck --db-attach=yes --leak-check=full --track-origins=yes ./test-stdio-leak ==38243== Memcheck, a memory error detector ==38243== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==38243== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==38243== Command: ./test-stdio-leak ==38243== Leaky! ==38243== ==38243== HEAP SUMMARY: ==38243== in use at exit: 4,096 bytes in 1 blocks ==38243== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated ==38243== ==38243== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1 ==38243== at 0x6DDE1: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==38243== by 0x179E8F: __smakebuf (makebuf.c:72) ==38243== by 0x179D69: __swsetup (wsetup.c:81) ==38243== by 0x1795EB: __sfvwrite (fvwrite.c:66) ==38243== by 0x149D21: puts (puts.c:68) ==38243== by 0x804858C: main (leakc.c:5) ==38243== ==38243== LEAK SUMMARY: ==38243== definitely lost: 0 bytes in 0 blocks ==38243== indirectly lost: 0 bytes in 0 blocks ==38243== possibly lost: 0 bytes in 0 blocks ==38243== still reachable: 4,096 bytes in 1 blocks ==38243== suppressed: 0 bytes in 0 blocks ==38243== ==38243== For counts of detected and suppressed errors, rerun with: -v ==38243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) If you look in lib/libc/stdio/findfp.c, you will see near the bottom: /* * exit() calls _cleanup() through *__cleanup, set whenever we * open or buffer a file. This chicanery is done so that programs * that do not use stdio need not link it all in. * * The name `_cleanup' is, alas, fairly well known outside stdio. */ void _cleanup() { /* (void) _fwalk(fclose); */ (void) _fwalk(__sflush); /* `cheating' */ } For some reason, since the original BSD 4.4 Lite Lib Sources, the stdio files are only flushed, not closed, at exit. In practice, it will not matter much, as the kernel will cleanup any left-overs when the process dies. It is probably best to put this leak on valgrind's ignore list.