2015-06-17 2 views
6

ich auf einem Klon der malloc (3) Funktionen arbeite (malloc, realloc und free jetzt).Individuelle Allocator: Valgrind zeigt 7 Allocs, 0 frees, keine Lecks

Ich möchte Unterstützung für Valgrind hinzufügen. Ich verwende these docs. Nachdem jedoch Anrufe an die VALGRIND_MEMPOOL_FREE, VALGRIND_MEMPOOL_ALLOC und VALGRIND_CREATE_MEMPOOL Makros hinzufügen, ich folgendes von Valgrind erhalten:

==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 

Dies ist trotz meiner realloc calling VALGRIND_MEMPOOL_FREE und meine free calling VALGRIND_MEMPOOL_FREE.

Was könnte die Ursache dafür sein?

+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) und [https://bugs.kde.org/show_bug]. cgi? id = 233298] (https://bugs.kde.org/show_bug.cgi?id=233298). – 4566976

Antwort

5

Was könnte die Ursache dafür sein?

Dies ist auf einen Fehler in Valgrind zurückzuführen. Sehen Sie die link zum Valgrind Bug Tracker in meinem Kommentar zu Ihrer Antwort.

Von den anderen link in meinem Kommentar:

Eine oberflächliche Suche durch den Quellcode zeigt an, dass MEMPOOL_ALLOC Anrufe new_block, die cmalloc_n_mallocs erhöht, aber es gibt keine entsprechende Änderung cmalloc_n_frees in 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

Das ist interessant, danke für den Hinweis! Obwohl ich nicht sicher bin, ob es tatsächlich das Problem ist. Ich sehe die 'cmalloc_n_frees' Variable, die in 3.10 inkrementiert wird, was die Version ist, in der ich bin (die Version von dem Fehlerbericht sind 3.5 und 3.6). 'cmalloc_n_frees' wird in' memcheck/mc_malloc_wrappers.c' in den Zeilen 479/522 (Quelle: http://valgrind.org/downloads/current.html) inkrementiert. Außerdem bin ich ein wenig skeptisch, wie das Valgrind-Entwicklerteam einen so offensichtlichen Fehler übersehen haben könnte. Denn der Standard "malloc" meldet Valgrind gut. Ich benutze 'DESTROY_MEMPOOL' atm nicht. Ist es erforderlich? – conradkdotcom

+0

@conradk Die relevante Funktion ist 'mempool_free' in Zeile 861, wo der' cmalloc_n_frees' nicht inkrementiert wird."mempool_alloc" in Zeile 832 ruft "new_block" auf, wobei "cmalloc_n_mallocs" inkrementiert wird, aber "mempool_free" ruft nicht "handle_free" auf, wobei "cmalloc_n_mtrecs" inkrementiert worden wäre. Das Valgrind-Entwicklerteam hat den Bug nicht übersehen. Es ist in ihrem Bug-Tracker, aber es ist seltsam, dass es nach so langer Zeit (mehr als fünf Jahre) noch nicht behoben ist. – 4566976

+0

@conradk 'VALGRIND_DESTROY_MEMPOOL' ändert nichts in der Ausgabe. Ich habe ein Beispiel hinzugefügt. – 4566976

0

von hier genommen: http://valgrind.10908.n7.nabble.com/VALGRIND-MEMPOOL-FREE-not-reflected-in-heap-summary-td42789.html

Eine oberflächliche Suche durch den Quellcode zeigt an, dass MEMPOOL_ALLOC Anrufe new_block, die cmalloc_n_mallocs erhöht, aber es gibt keine entsprechende Änderung cmalloc_n_frees in MEMPOOL_FREE. Hier ist ein Patch, der es am Ende von MEMPOOL_FREE erhöht. Dies gibt mir das Verhalten, das ich erwarte.

+0

'Hier ist ein Patch' Wo? – Mast

+0

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

+0

Wenn Sie Copypaste aus anderen Quellen kopieren, wird erwartet, dass Sie diesen Text als Zitat markieren! – alk