2015-05-28 15 views
5

Halten Sie erreichbar Speicherverlust für printf und scanf Anweisung. Ich brauche überhaupt keine Lecks. Wenn ich den Bericht ausführe, sagt er, dass ich die erreichbaren Lecks an einer Druckanweisung und einer Scan-Anweisung bekomme. Meine Frage ist, wie ich die Lecks beheben kann? HierValgrind Memory Leak Erreichbar

ist der valgrind Bericht:

kidslove-MacBook: src kidslove $ valgrind --leak-check = full --show-Leck-Arten = alle ./a.out

==6405== Memcheck, a memory error detector 
==6405== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. 
==6405== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info 
==6405== Command: ./a.out 
==6405== 
Enter File Name: input2.txt 
1. Print the array sorted by street. 
2. Print the array sorted by city. 
3. Print the array sorted by state then city 
4. Print the array sorrted by zip. 
5. Quit 

--> 5 
==6405== 
==6405== HEAP SUMMARY: 
==6405==  in use at exit: 42,554 bytes in 422 blocks 
==6405== total heap usage: 513 allocs, 91 frees, 53,707 bytes allocated 
==6405== 
==6405== 4,096 bytes in 1 blocks are still reachable in loss record 77 of 78 
==6405== at 0x1000076C1: malloc (vg_replace_malloc.c:303) 
==6405== by 0x1001F1836: __smakebuf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x100206387: __swsetup (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x10022075D: __v2printf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x100220C80: __xvprintf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001F6B71: vfprintf_l (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001F49D7: printf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1000010B3: openFile (hw5.c:15) 
==6405== by 0x100001CD5: main (cscd240hw5.c:9) 
==6405== 
==6405== 4,096 bytes in 1 blocks are still reachable in loss record 78 of 78 
==6405== at 0x1000076C1: malloc (vg_replace_malloc.c:303) 
==6405== by 0x1001F1836: __smakebuf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001F4E99: __srefill0 (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001F4F94: __srefill (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001FC00D: __svfscanf_l (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1001F515D: scanf (in /usr/lib/system/libsystem_c.dylib) 
==6405== by 0x1000010C8: openFile (hw5.c:16) 
==6405== by 0x100001CD5: main (cscd240hw5.c:9) 
==6405== 
==6405== LEAK SUMMARY: 
==6405== definitely lost: 0 bytes in 0 blocks 
==6405== indirectly lost: 0 bytes in 0 blocks 
==6405==  possibly lost: 0 bytes in 0 blocks 
==6405== still reachable: 8,192 bytes in 2 blocks 
==6405==   suppressed: 34,362 bytes in 420 blocks 
==6405== 
==6405== For counts of detected and suppressed errors, rerun with: -v 
==6405== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15) 

Teil meines Programm, das das Leck zurückkehrt:

FILE *openFile() { 
    char name[20]; 
    FILE *fin; 

    do { 
    printf("Enter File Name: "); //line 15 leak 
    scanf("%s", name); // line 16 leak 
    fin = fopen(name, "r"); 
    }while(fin == NULL); 
    return fin; 

} 

Die ursprüngliche Anruf Wesen:

fin = openFile(); 
+0

'fopen' ohne' fclose' –

+0

Anrufer wird es schließen. –

+0

@ Ôrel: Der Bericht zeigt auf printf/scant. Und man würde hoffen, dass der Schlüssel woanders ist ... –

Antwort

3

Die Standard-C-Bibliothek auf Ihrem System scheint nicht die Puffer zu befreien, die stdio verwendet. Das ist kein Grund zur Sorge. Das System gibt den Speicher frei, wenn das Programm beendet wird.

In der Regel enthalten Pakete für Valgrind, die vom Betriebssystem bereitgestellt werden, Unterdrückungsdateien, die valgrind anweisen, keine der erwarteten Lecks zu melden. Entweder du verwendest ein nicht-standardmäßiges Paket von Valgrind, du hast die Standard-Unterdrückungen deaktiviert oder wer auch immer Valgrind auf diesem System gebaut hat, hat nicht gestört.