Why does a simple C hello-world program, when run with Valgrind, show a \'still reachable\' memory warning despite not allocating any memory?

The Trivial Program and Output

The trivial program (named ValgrindTest) you provided is a simple hello-world program written in C .

#include <iostream>
int main() {
  return 0;
}

When this program is run using Valgrind (version 3.10.1), it reports that there are 72,704 bytes in 1 block that are still reachable:

$ valgrind --leak-check=full --track-origins=yes --show-reachable=yes ./ValgrindTest
==27671== Memcheck, a memory error detector
==27671== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==27671== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==27671== Command: ./ValgrindTest
==27671==
==27671==
==27671== HEAP SUMMARY:
==27671==     in use at exit: 72,704 bytes in 1 blocks
==27671==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==27671==
==27671== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==27671==    at 0x4C2AB9D: malloc (vg_replace_malloc.c:296)
==27671==    by 0x4EC060F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==27671==    by 0x400F305: call_init.part.0 (dl-init.c:85)
==27671==    by 0x400F3DE: call_init (dl-init.c:52)
==27671==    by 0x400F3DE: _dl_init (dl-init.c:134)
==27671==    by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)
==27671==
==27671== LEAK SUMMARY:
==27671==    definitely lost: 0 bytes in 0 blocks
==27671==    indirectly lost: 0 bytes in 0 blocks
==27671==      possibly lost: 0 bytes in 0 blocks
==27671==    still reachable: 72,704 bytes in 1 blocks
==27671==         suppressed: 0 bytes in 0 blocks
==27671==
==27671== For counts of detected and suppressed errors, rerun with: -v
==27671== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The Cause of the Still Reachable Warning

You're not concerned about whether or not to worry about still reachable warnings, but you did ask about how simply including a standard library header could cause a still reachable warning, when no objects from that library were allocated in the program itself.

The answer is that the C standard library uses its own memory management system, which allocates memory from the operating system and then manages that memory itself. When you include a standard library header, you are essentially linking your program against the standard library code, which includes this memory management system. As a result, the memory that is allocated by the standard library code is still reachable from your program, even if you don't explicitly allocate any objects from the standard library yourself.

How to Fix the Still Reachable Warning

There are two ways to fix the still reachable warning:

1. Configure your compiler to use a different memory management system. This can be done by setting the -D_GLIBCXX_FORCE_NEW=1 flag when you compile your program. This flag tells the compiler to use the malloc() and free() functions instead of the standard library's memory management system.

2. Ignore the still reachable warning. If you're not concerned about memory leaks, you can simply ignore the still reachable warning. To do this, you can set the --leak-check=no flag when you run Valgrind:

   valgrind --leak-check=no ./ValgrindTest

Conclusion

It's important to remember that still reachable warnings are not necessarily indicative of a memory leak. In this case, the still reachable warning is caused by the standard library's memory management system, and it can be safely ignored if you're not concerned about memory leaks.

The above is the detailed content of Why does a simple C hello-world program, when run with Valgrind, show a \'still reachable\' memory warning despite not allocating any memory?. For more information, please follow other related articles on the PHP Chinese website!