C++ 程序什么都不做，但 Valgrind 显示 memory alloc

Question

I was toying around with Valgrind, when I noticed something weird: my C++ program does nothing, yet there is 1 memory alloc and 1 free.

My simple program:

int main() {
  return 0;
}

when compiled with g++ and checked with Valgrind

> g++ main.cpp
> valgrind --leak-check=full --track-origins=yes ./a.out

==40790== Memcheck, a memory error detector
==40790== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40790== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40790== Command: ./a.out
==40790== 
==40790== 
==40790== HEAP SUMMARY:
==40790==     in use at exit: 0 bytes in 0 blocks
==40790==   total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==40790== 
==40790== All heap blocks were freed -- no leaks are possible
==40790== 
==40790== For lists of detected and suppressed errors, rerun with: -s
==40790== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

My question: My program does nothing. Where does the alloc and free come from?

Interestingly enough, the same program compiled with gcc, shows zero allocs and frees:

> gcc main.c
> valgrind --leak-check=full --track-origins=yes ./a.out
==40740== Memcheck, a memory error detector
==40740== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40740== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40740== Command: ./a.out
==40740== 
==40740== 
==40740== HEAP SUMMARY:
==40740==     in use at exit: 0 bytes in 0 blocks
==40740==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==40740== 
==40740== All heap blocks were freed -- no leaks are possible
==40740== 
==40740== For lists of detected and suppressed errors, rerun with: -s
==40740== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Follow up question: Why do the two memory allocations differ, for the same piece of code?

compiler: gcc (GCC) 10.1.0
valgrind: valgrind-3.16.0.GIT

Answer 1

The main function is the entry point of your code. It doesn't have to be (and seldom is) the entry point to the process for the operating system that is loading your program.

There's usually plenty of code running first to set up things needed for the standard library (like setting up the standard I/O streams, and fetching the actual arguments from the operating system) before your main function is called.

And it's important to note that the main function is called like any other function. Once it returns it will return to the initialization code which will now clean up after itself (like freeing memory it might have allocated, and closing streams, etc.).