Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Mar 2012 17:52:00 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        "Ina J." <inarvaj@gmail.com>
Cc:        freebsd-stable@FreeBSD.org
Subject:   Re: FreeBSD 9.0: Valgrind leaks memory
Message-ID:  <4F636FB0.3090305@FreeBSD.org>
In-Reply-To: <CAPKAR4KGO31ZyJuZi0x=iF=UnUVfxXGWWnOLw7n9Nd7nhXhc3Q@mail.gmail.com>
References:  <CAPKAR4KGO31ZyJuZi0x=iF=UnUVfxXGWWnOLw7n9Nd7nhXhc3Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <iostream>
> 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 <stdio.h>

  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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F636FB0.3090305>