Hi,
I tried to find a thread about this, but I didn't and in this
thread<http://forums.freebsd.org/showthread.php?t=16468>trasz
suggested to send message to the mailing list.
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;
}
I compile it simply with command:
g++ test.cc
And then run it in valgrind:
valgrind --show-reachable=yes --tool=memcheck --db-attach=yes
--leak-check=full --track-origins=yes ./a.out
And Valgrind outputs this:
### V AL G R I N D O U T P U T ###
==39783== Memcheck, a memory error detector
==39783== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==39783== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==39783== Command: ./a.out
==39783=Valgrind leaks memory
==39783===39783== HEAP SUMMARY:
==39783== in use at exit: 4,096 bytes in 1 blocks
==39783== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==39783===39783== 4,096 bytes in 1 blocks are still reachable in loss record 1
of 1
==39783== at 0x5BF98: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==39783== by 0x26B503: ??? (in /lib/libc.so.7)
==39783== by 0x26B3C4: ??? (in /lib/libc.so.7)
==39783== by 0x26AF12: ??? (in /lib/libc.so.7)
==39783== by 0x26AAB4: fwrite (in /lib/libc.so.7)
==39783== by 0xA1135: ??? (in /usr/lib/libstdc++.so.6)
==39783== by 0xDC3C7: std::basic_ostream<char,
std::char_traits<char> >&
std::__ostream_insert<char,
std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char> >&, char
const*, int) (in
/usr/lib/libstdc++.so.6)
==39783== by 0xDC5DB: std::basic_ostream<char,
std::char_traits<char> >&
std::operator<< <std::char_traits<char>
>(std::basic_ostream<char,
std::char_traits<char> >&, char const*) (in
/usr/lib/libstdc++.so.6)
==39783== by 0x80488C4: main (in /usr/home/ina/test/a.out)
==39783===39783== LEAK SUMMARY:
==39783== definitely lost: 0 bytes in 0 blocks
==39783== indirectly lost: 0 bytes in 0 blocks
==39783== possibly lost: 0 bytes in 0 blocks
==39783== still reachable: 4,096 bytes in 1 blocks
==39783== suppressed: 0 bytes in 0 blocks
==39783===39783== For counts of detected and suppressed errors, rerun with: -v
==39783== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
In my Ubuntu, Valgrind detects no memory leaks. Although, those reported
leaks are just reachable bytes, but there shouldn't be any of them.
On my Ubuntu g++ and Valgrind versions are as follows:
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
valgrind-3.6.0.SVN-Debian
And on FreeBSD:
g++ (GCC) 4.2.1 20070831 patched [FreeBSD]
valgrind-3.6.1
With my actual code, Valgrind reports a lot more memory leaks and also
those mentioned on the thread I linked, but sample code is enough to
produce errors which shouldn't exist.
-Ina
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.
On Fri, Mar 16, 2012 at 01:23:48PM +0200, Ina J. wrote:> Hi, > > I tried to find a thread about this, but I didn't and in this > thread<http://forums.freebsd.org/showthread.php?t=16468>trasz > suggested to send message to the mailing list.http://valgrind.org/docs/manual/dist.readme-packagers.html -- Do not ship your Linux distro with a completely stripped /lib/ld.so. At least leave the debugging symbol names on -- line number info isn't necessary. If you don't want to leave symbols on ld.so, alternatively you can have your distro install ld.so's debuginfo package by default, or make ld.so.debuginfo be a requirement of your Valgrind RPM/DEB/whatever. Reason for this is that Valgrind's Memcheck tool needs to intercept calls to, and provide replacements for, some symbols in ld.so at startup (most importantly strlen). If it cannot do that, Memcheck shows a large number of false positives due to the highly optimised strlen (etc) routines in ld.so. This has caused some trouble in the past. As of version 3.3.0, on some targets (ppc32-linux, ppc64-linux), Memcheck will simply stop at startup (and print an error message) if such symbols are not present, because it is infeasible to continue. It's not like this is going to cost you much space. We only need the symbols for ld.so (a few K at most). Not the debug info and not any debuginfo or extra symbols for any other libraries.