1

I'm just starting to try out Valgrind, and as a control, I ran it on a trivial C file and got unexpected results. Here are the contents of blank.c:

int main() {
  return 0;
}

I compiled with gcc -o blank blank.c

I ran valgrind --tool=memcheck ./blank and got this output:

==7877== Memcheck, a memory error detector
==7877== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7877== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7877== Command: ./blank
==7877== 
==7877== 
==7877== HEAP SUMMARY:
==7877==     in use at exit: 22,177 bytes in 185 blocks
==7877==   total heap usage: 267 allocs, 82 frees, 28,377 bytes allocated
==7877== 
==7877== LEAK SUMMARY:
==7877==    definitely lost: 0 bytes in 0 blocks
==7877==    indirectly lost: 0 bytes in 0 blocks
==7877==      possibly lost: 0 bytes in 0 blocks
==7877==    still reachable: 0 bytes in 0 blocks
==7877==         suppressed: 22,177 bytes in 185 blocks
==7877== 
==7877== For counts of detected and suppressed errors, rerun with: -v
==7877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I don't understand why the Heap Summary shows so much memory in use and so many allocs when my program doesn't do anything. How do I understand/fix this?

I'm not sure what other information would be helpful, but gcc --version returns 

Configured with: --  prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

---EDIT--- Like the other question which this one duplicates, if I run my trivial C program on a Linux machine, everything looks clean and pretty.

Ben Lindsay
  • 1,686
  • 4
  • 23
  • 44
  • 3
    that's only about 20Kb. Probably space reserved by the C bootstrap to copy environment variables and suchlike... – kuroi neko Feb 21 '16 at 17:42
  • @kuroineko Shouldn't the goal of a clean program be to have 0 bytes in use at exit though? And aren't the number of allocs supposed to match the number of frees? – Ben Lindsay Feb 21 '16 at 17:47
  • @2501 Thanks for pointing that post out. I missed that one. However, my situation seems slightly different. That post seems to suggest that `valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./blank` should make the number of allocs match the number of frees, but running that doesn't change anything for me. – Ben Lindsay Feb 21 '16 at 17:51
  • @BenLindsay See the answer. – 2501 Feb 21 '16 at 17:52
  • @2501 OK, so by using `-v` I can see a gross list of all the default libraries that contribute to the suppressed leaks, but will I just never be able to get the number of allocs to match the number of frees? Should I just care about the leak summary? – Ben Lindsay Feb 21 '16 at 17:57
  • 1
    @BenLindsay 'goal of a clean program be to have 0 bytes in use at exit' well, that is an unreasonable goal in many, many cases. Cleanliness is not next to Godliness in software development, it's next to the trash bin for programs that do not shut down promptly, generate segfaults/AV on close, are riddled with difficult-to-test shutdown code and generally misbehave on termination. – Martin James Feb 21 '16 at 17:57
  • 1
    @BenLindsay Yes you should! Alas you will have to learn to interpret the output. – 2501 Feb 21 '16 at 17:58
  • 1
    "C" and "clean" are not easily matched :). The C bootstrap is a special case, since its life expectancy is the same as the process itself. There is no benefit from freeing memory just before the process terminates and releases all resources anyway. – kuroi neko Feb 21 '16 at 17:58
  • 1
    Yeah - the leak summary shows no leaks. Looks fine to me:) – Martin James Feb 21 '16 at 17:59
  • OK, I'm content then. If someone wants to put an answer up that summarizes how to think about the results I'll mark it correct. Otherwise I'll throw one up. – Ben Lindsay Feb 21 '16 at 18:01

0 Answers0