2015-06-17 15 views
6

Pracuję nad klonem malloc (3) funkcji (malloc, realloc i free na razie).klienta podzielnik: Valgrind pokazuje 7 ALLOCS, 0 FreeS, żadnych przecieków

Chciałbym dodać wsparcie dla Valgrind. Używam these docs. Jednak po dodaniu wywołań makr VALGRIND_MEMPOOL_FREE, VALGRIND_MEMPOOL_ALLOC i VALGRIND_CREATE_MEMPOOL, mam następujący z Valgrind:

==22303== HEAP SUMMARY: 
==22303==  in use at exit: 0 bytes in 0 blocks 
==22303== total heap usage: 7 allocs, 0 frees, 2,039 bytes allocated 
==22303== 
==22303== All heap blocks were freed -- no leaks are possible 

to pomimo mojego realloc calling VALGRIND_MEMPOOL_FREE i mój free calling VALGRIND_MEMPOOL_FREE.

Co może być tego przyczyną?

+4

See [http://valgrind.10908.n7.nabble.com/VALGRIND-MEMPOOL-FREE-not-reflected-in-heap-summary-td42789.html ] (http://valgrind.10908.n7.nabble.com/VALGRIND-MEMPOOL-FREE-not-reflected-in-heap-summary-td42789.html) i [https://bugs.kde.org/show_bug. cgi? id = 233298] (https://bugs.kde.org/show_bug.cgi?id=233298). – 4566976

Odpowiedz

5

Co może być tego przyczyną?

Jest to spowodowane błędem w valgrind. Zobacz link do trackera błędów valgrind w moim komentarzu do twojej odpowiedzi.

Z drugiej link w moim komentarzu:

Pobieżna wyszukiwania poprzez kod źródłowy wskazuje MEMPOOL_ALLOC rozmowy new_block, który zwiększa cmalloc_n_mallocs, ale nie ma odpowiada zmiana cmalloc_n_frees w MEMPOOL_FREE.

/* valgrind.c */ 
#include <valgrind/valgrind.h> 

int main(int argc, char *argv[]) { 
    char pool[100]; 

    VALGRIND_CREATE_MEMPOOL(pool, 0, 0); 
    VALGRIND_MEMPOOL_ALLOC(pool, pool, 8); 
    VALGRIND_MEMPOOL_FREE(pool, pool); 
    VALGRIND_DESTROY_MEMPOOL(pool); 
    return 0; 
} 

$ gcc valgrind.c -g 
$ valgrind --leak-check=full --show-leak-kinds=all ./a.out 
==10186== Memcheck, a memory error detector 
==10186== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. 
==10186== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info 
==10186== Command: ./a.out 
==10186== 
==10186== 
==10186== HEAP SUMMARY: 
==10186==  in use at exit: 0 bytes in 0 blocks 
==10186== total heap usage: 1 allocs, 0 frees, 8 bytes allocated 
==10186== 
==10186== All heap blocks were freed -- no leaks are possible 
==10186== 
==10186== For counts of detected and suppressed errors, rerun with: -v 
==10186== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 
$ 
+0

To jest interesujące, dziękuję za podpowiedź! Chociaż nie jestem pewien, czy to rzeczywiście problem. Widzę zmienną 'cmalloc_n_frees' zwiększaną o 3.10, która jest wersją, na której się znajduję (wersja z raportu o błędzie to 3.5 i 3.6). 'cmalloc_n_frees' jest inkrementowane w' memcheck/mc_malloc_wrappers.c' w liniach 479/522 (źródło: http://valgrind.org/downloads/current.html). Jestem też trochę sceptyczny co do tego, jak zespół programistów Valgrind mógł przegapić tak oczywisty błąd. W końcu standardowe "malloc" zgłasza się dobrze z Valgrind. Nie używam bankomatu 'DESTROY_MEMPOOL'. Czy jest to wymagane? – conradkdotcom

+0

@conradk Odpowiednią funkcją jest 'mempool_free' w linii 861, gdzie' cmalloc_n_frees' nie jest inkrementowane.'mempool_alloc' w linii 832 wywołuje' new_block', gdzie 'cmalloc_n_mallocs' jest inkrementowany, ale' mempool_free' nie wywołuje 'handle_free', gdzie' cmalloc_n_frees' zostałoby zwiększone. Zespół programistów Valgrind nie przegapił błędu. Jest w ich bug trackerze, ale to dziwne, że nie jest jeszcze naprawiony po tak długim czasie (ponad pięć lat). – 4566976

+0

@conradk 'VALGRIND_DESTROY_MEMPOOL' nie zmienia niczego w danych wyjściowych. Dodałem do tego przykład. – 4566976

0

Zrobione stąd: http://valgrind.10908.n7.nabble.com/VALGRIND-MEMPOOL-FREE-not-reflected-in-heap-summary-td42789.html

Pobieżna wyszukiwania poprzez kod źródłowy wskazuje MEMPOOL_ALLOC rozmowy new_block, który zwiększa cmalloc_n_mallocs, ale nie ma odpowiada zmiana cmalloc_n_frees w MEMPOOL_FREE. Oto łatka , która zwiększa ją na samym końcu MEMPOOL_FREE. Daje to zachowanie, którego oczekuję od .

+0

'Tutaj jest łatka' Gdzie? – Mast

+0

http://valgrind.10908.n7.nabble.com/attachment/42790/0/patch –

+0

JEŚLI jesteś koprodukcją z innych źródeł, musisz oznaczyć ten tekst jako cytat! – alk

Powiązane problemy