Valgrind Memory Leak Reachable

Question

Keep getting reachable memory leak for printf and scanf statement. I'm needing to have no leaks at all. When I run the report it says that I get the reachable leaks at a print statement and scan statement. My question is how to I fix the leaks?

Here is the valgrind report:

kidslove-MacBook:src kidslove$ valgrind --leak-check=full --show-leak-kinds=all ./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)

Part of my program that is returning the leaks:

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;

}

The original call being:

fin = openFile();

@Ôrel: the report points at printf/scant. And one would hope that the fclose is elsewhere... — Oliver Charlesworth, May 28 '15 at 07:27
You could use write instead of printf and read instead of scanf (though the latter will ask for a bit of work) — Eregrith, May 28 '15 at 07:38
@OliverCharlesworth to manage "still reachable blocks" allocated by printf/scanf — Eregrith, May 28 '15 at 07:40
possible duplicate of [Valgrind showing memory leak for printf and unused blocks](http://stackoverflow.com/questions/26409611/valgrind-showing-memory-leak-for-printf-and-unused-blocks) — Eregrith, May 28 '15 at 07:41
@Eregrith: obfuscating perfectly good code to satisfy Valgrind doesn't seem preferable... — Oliver Charlesworth, May 28 '15 at 07:42

score 3 · Answer 1 · answered May 28 '15 at 07:44

The standard C library on your system doesn't seem to bother freeing buffers that stdio uses. This is nothing to worry about. The system frees the memory when your program exits.

Usually packages for valgrind provided by the operating system contain suppression files that tell valgrind to not report lots of those expected leaks. Either you're using a non-standard package of valgrind, you've disabled the standard suppressions or whoever built valgrind on that system didn't bother.

Valgrind Memory Leak Reachable

1 Answers1

Linked