printf und Memory Leak (Valgrind, FreeBSD)

Morfio

Well-Known Member
Hallo,

ich habe ein lustige Phänomen: printf (oder puts) scheint 4kb zu allozieren (einmalig, egal, wie oft man die Funktionen aufruft), aber nicht mehr freizugeben (FreeBSD 8.0). Unter Linux (Gentoo + Ubuntu) tritt das Verhalten nicht auf:

Code
Code:
#include <stdio.h>

int main() {
    printf("Hallo Welt\n");
    return 0;
}

Valgrind (FreeBSD)
$ valgrind --leak-check=full --show-reachable=yes ./a.out
==20198== Memcheck, a memory error detector
==20198== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20198== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20198== Command: ./a.out
==20198==
Hallo Welt
==20198==
==20198== HEAP SUMMARY:
==20198== in use at exit: 4,096 bytes in 1 blocks
==20198== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==20198==
==20198== LEAK SUMMARY:
==20198== definitely lost: 0 bytes in 0 blocks
==20198== indirectly lost: 0 bytes in 0 blocks
==20198== possibly lost: 0 bytes in 0 blocks
==20198== still reachable: 0 bytes in 0 blocks
==20198== suppressed: 4,096 bytes in 1 blocks
==20198==
==20198== For counts of detected and suppressed errors, rerun with: -v
==20198== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Valgrind (Gentoo)
valgrind ./a.out
==20844== Memcheck, a memory error detector.
==20844== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==20844== Using LibVEX rev 1804, a library for dynamic binary translation.
==20844== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==20844== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==20844== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==20844== For more details, rerun with: -v
==20844==
Hallo Welt
==20844==
==20844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==20844== malloc/free: in use at exit: 0 bytes in 0 blocks.
==20844== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==20844== For counts of detected errors, rerun with: -v
==20844== All heap blocks were freed -- no leaks are possible.

Kompiliert wird mit

gcc -Wall -g test.c

Kennt das jemand? Ist das irgendwie definiert oder könnte es sich um einen Fehler handeln?

Viele Grüße, Morfio
 
Ich kann das Problem hier auch mit einer entsprechenden C++-Variante reproduzieren.

Programm:
Code:
#include <iostream>
using namespace std;

int main() {
    cout << "Hello World!" << endl;
    return 0;
}

Kompiliert mit
Code:
g++ -Wall -g leak.cc -o leak

Valgrind-Ausgabe:
Code:
$ valgrind -v --leak-check=full --show-reachable=yes ./leak
==73094== Memcheck, a memory error detector
==73094== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==73094== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==73094== Command: ./leak
==73094== 
--73094-- Valgrind options:
--73094--    -v
--73094--    --leak-check=full
--73094--    --show-reachable=yes
--73094-- Contents of /proc/version:
--73094-- Arch and hwcaps: X86, x86-sse1
--73094-- Page sizes: currently 4096, max supported 4096
--73094-- Valgrind library directory: /usr/local/lib/valgrind
--73094-- Reading syms from /libexec/ld-elf.so.1 (0x10000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /tmp/leak (0x8048000)
--73094-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--73094-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-x86-freebsd.so (0x54000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so (0x56000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /usr/lib/libstdc++.so.6 (0x5e000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /lib/libm.so.5 (0x151000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /lib/libgcc_s.so.1 (0x16a000)
--73094--    object doesn't have a symbol table
--73094-- Reading syms from /lib/libc.so.7 (0x175000)
--73094--    object doesn't have a symbol table
--73094-- REDIR: 0x2621e0 (memset) redirected to 0x5a2f0 (memset)
--73094-- REDIR: 0x262220 (memcpy) redirected to 0x5b270 (memcpy)
--73094-- REDIR: 0x25b908 (strlen) redirected to 0x59ea0 (strlen)
--73094-- REDIR: 0x1e5370 (malloc) redirected to 0x58f10 (malloc)
--73094-- REDIR: 0x25f974 (memchr) redirected to 0x5a170 (memchr)
Hello World!
==73094== 
==73094== HEAP SUMMARY:
==73094==     in use at exit: 4,096 bytes in 1 blocks
==73094==   total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==73094== 
==73094== Searching for pointers to 1 not-freed blocks
==73094== Checked 378,448 bytes
==73094== 
==73094== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1
==73094==    at 0x58F95: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==73094==    by 0x25FBA3: ??? (in /lib/libc.so.7)
==73094==    by 0x25FA64: ??? (in /lib/libc.so.7)
==73094==    by 0x25F5F0: ??? (in /lib/libc.so.7)
==73094==    by 0x25F172: fwrite (in /lib/libc.so.7)
==73094==    by 0x9E305: ??? (in /usr/lib/libstdc++.so.6)
==73094==    by 0xD96CD: 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)
==73094==    by 0xD98DB: 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)
==73094==    by 0x8048894: main (leak.cc:5)
==73094== 
==73094== LEAK SUMMARY:
==73094==    definitely lost: 0 bytes in 0 blocks
==73094==    indirectly lost: 0 bytes in 0 blocks
==73094==      possibly lost: 0 bytes in 0 blocks
==73094==    still reachable: 4,096 bytes in 1 blocks
==73094==         suppressed: 0 bytes in 0 blocks
==73094== 
==73094== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==73094== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Ich wollte es noch auf einer Solaris-Büchse ausprobieren, aber da habe ich keinen Valgrind installiert...
 
Zurück
Oben