1

Each time I compile a program (no matter what it is) and then check it with valgrind, I get a message saying:

==20455== HEAP SUMMARY:
==20455==     in use at exit: 72,704 bytes in 1 blocks
==20455==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated

I even got this when trying to writing this code:

int main{
    return 0;
}

any idea on where or how to find this memory leak? and why is it happening on every single program?

trincot
  • 317,000
  • 35
  • 244
  • 286
CS2000
  • 51
  • 4
  • Which memory leak are you talking about? – πάντα ῥεῖ Jan 12 '21 at 17:35
  • each time i write a program, and compile it, when i check valgrind i get that there's a memory leak, even when the whole program has one line that is " return 0; ", why is that happening(i'm not allocating memory in the code above)? is there something that should be deleted from the heap? – CS2000 Jan 12 '21 at 17:39
  • 1
    Are you linking some libraries? – Mario Demontis Jan 12 '21 at 17:39
  • I guess that you did not forget to compile with `-g` option – Damien Jan 12 '21 at 17:40
  • 2
    Hard to understand the downvotes here. Seems a reasonable question to me. – Paul Sanders Jan 12 '21 at 17:40
  • @AdanSuleiman This is what a memory leak would look like: http://coliru.stacked-crooked.com/a/a57729115952a608 – πάντα ῥεῖ Jan 12 '21 at 17:42
  • @Damien How would that affect memory allocation? – πάντα ῥεῖ Jan 12 '21 at 17:44
  • Do you link any libraries? Do you include any header files, especially ``? What is your compiler and compilation flags? – Daniel Langr Jan 12 '21 at 17:44
  • I'm not linking libraries, and I tried adding -g but it didn't fix it – CS2000 Jan 12 '21 at 17:47
  • 1
    @AdanSuleiman That's not a memory leak reported by valgrind, just the top of the heap memory that was allocated for the whole process. There's a number of process environment resources (e.g. the `const char** argv` and `const char** envp` passed to `main()` as parameters). Also some runtime stuff which is linked by default, might allocate memory whithout you taking even notice. – πάντα ῥεῖ Jan 12 '21 at 17:48
  • @πάντα ῥεῖ In the past, I sometimes got strange behavior with valgrind and code not compiled with `-g` – Damien Jan 12 '21 at 17:49
  • @Damien Could have been something with dependency injected memory sanitizers incompatible with valgrind. – πάντα ῥεῖ Jan 12 '21 at 17:51
  • Note that empty source code does not at all generate an empty program. I just checked a program built from this minimal source code with static linking. Its disassembly with objdump revealed more than **200 thousands assembly instructions** with a lot of `malloc` calls (`__libc_malloc`). The implementation is free not to call `free` if it knows that the memory will be released at the process end automatically (by OS). – Daniel Langr Jan 12 '21 at 18:01
  • these are the flags i'm using: g++ -std=c++11 -Wall -Werror -pedantic-errors -DNDEBUG temp.cpp -g -o temp – CS2000 Jan 12 '21 at 18:04
  • @DanielLangr can you please explain more on how can I solve such problem? – CS2000 Jan 12 '21 at 18:06
  • @AdanSuleiman You didn't understand. There is simply no problem. Consider even this program: `int main() { int* ptr = new int{0}; }`. This is a perfectly legal program, even though Vaglrind will report a leak. (In some cases, skipping deallocation may even considerably speed up the process termination; for example, we use this technique in our HPC application where hundreds of millions of allocations may occur.) – Daniel Langr Jan 12 '21 at 18:26
  • @DanielLangr first of all, thank you. This program has a clear memory allocation using new, what i dont get is how "return 0" is making valgrind report a leak? -i'm sorry i'm new to programming- – CS2000 Jan 12 '21 at 18:30
  • @AdanSuleiman It's not causing `return 0;`. Have you read my previous comments? The one about the generated 200k-instructions for your source code? Have you checked the link I mentioned? There are detailed answers and links to more material about this issue. – Daniel Langr Jan 12 '21 at 18:36
  • @AdanSuleiman If you are new to programming, I would suggest you not to care about these issues. If you want to study them, it's not for beginners. You would need to learn about how programs are compiled, how to disassemble them, what is the ELF format, how glibc is involved, what are syscalls (sbrk, mmap), what does a kernel do when the process is terminated, how does a heap work, and a lot more... – Daniel Langr Jan 12 '21 at 18:39

0 Answers0