I'm using OpenSSL's EVP routine and can not eliminate all still reachable memory. The tutorial linked above leaks this much:
==30413== LEAK SUMMARY:
==30413== definitely lost: 0 bytes in 0 blocks
==30413== indirectly lost: 0 bytes in 0 blocks
==30413== possibly lost: 0 bytes in 0 blocks
==30413== still reachable: 2,200 bytes in 27 blocks
==30413== suppressed: 0 bytes in 0 blocks
and with the addition of the answer here, I was able to get it down to:
==30437== LEAK SUMMARY:
==30437== definitely lost: 0 bytes in 0 blocks
==30437== indirectly lost: 0 bytes in 0 blocks
==30437== possibly lost: 0 bytes in 0 blocks
==30437== still reachable: 744 bytes in 13 blocks
==30437== suppressed: 0 bytes in 0 blocks
Is it possible to eliminate these? Is it something I should even bother with?
I've seen conflicting answers on SO stating that "still reachable" memory is a memory leak and others saying it isn't, hence my confusion.
Related
I am using Valgrind tool to understand the different types of memory leaks:
Directly lost,Indirectly lost Still reachable and possibly lost.
Ex1:
#include<stdio.h>
#include <stdlib.h>
main() {
int *p, i;
p = malloc(10*sizeof(int));
for(i = 0;i < 10;i++)
p[i] = i;
//free(p);
printf("Freed\n ");
}
LEAK SUMMARY:
==31770== definitely lost: 0 bytes in 0 blocks
==31770== indirectly lost: 0 bytes in 0 blocks
==31770== possibly lost: 20 bytes in 1 blocks
==31770== still reachable: 0 bytes in 0 blocks
==31770== suppressed: 0 bytes in 0 blocks
eg2:
main() {
int *p, i;
p = malloc(10*sizeof(int));
// printf("freed");
}
LEAK SUMMARY:
==14950== definitely lost: 0 bytes in 0 blocks
==14950== indirectly lost: 0 bytes in 0 blocks
==14950== possibly lost: 0 bytes in 0 blocks
==14950== still reachable: 40 bytes in 1 blocks
==14950== suppressed: 0 bytes in 0 blocks
If a uncomment the printf statement:
LEAK SUMMARY:
==15889== definitely lost: 40 bytes in 1 blocks
==15889== indirectly lost: 0 bytes in 0 blocks
==15889== possibly lost: 0 bytes in 0 blocks
==15889== still reachable: 0 bytes in 0 blocks
==15889== suppressed: 0 bytes in 0 blocks
Please explain me exactly about those different memory leaks.
A quick internet search leads to the following site:
http://valgrind.org/docs/manual/faq.html#faq.deflost
The details are in the Memcheck section of the user manual.
In short:
"definitely lost" means your program is leaking memory -- fix
those leaks!
"indirectly lost" means your program is leaking memory in a
pointer-based structure. (E.g. if the root node of a binary tree is
"definitely lost", all the children will be "indirectly lost".) If you
fix the "definitely lost" leaks, the "indirectly lost" leaks should go
away.
"possibly lost" means your program is leaking memory, unless
you're doing unusual things with pointers that could cause them to
point into the middle of an allocated block; see the user manual for
some possible causes. Use --show-possibly-lost=no if you don't want to
see these reports.
"still reachable" means your program is probably ok -- it didn't
free some memory it could have. This is quite common and often
reasonable. Don't use --show-reachable=yes if you don't want to see
these reports.
"suppressed" means that a leak error has been suppressed. There
are some suppressions in the default suppression files. You can ignore
suppressed errors.
Update:
The difference between "definitely lost" and "still reachable" is as follows:
Your memory is definitely lost if all references to it are gone and you did not free it before - the classical case of a memory leak.
It is still reachable when, at the end of your program's lifetime, you did not free all memory that was dynamically allocated but there are still valid references to it, so that it could have been freed.
Since all of the program's memory is freed at program termination anyway, this isn't usually a problem. However for a long running program and large memory allocations, it might be worth manually freeing those if you don't need them anymore.
Let me show you a simple example:
#include <stdio.h>
#include <stdlib.h>
char *still_reachable;
char *definitely_lost_global;
int main()
{
char *definitely_lost_local;
// allocate 10 bytes of memory -> will get lost
definitely_lost_local = malloc(10 * sizeof *definitely_lost_local);
// allocate 20 bytes of memory -> will get lost
definitely_lost_global = malloc(20 * sizeof *definitely_lost_global);
definitely_lost_global = NULL;
// Now there aren't any references to those 20 bytes anymore, so memory is lost.
// allocate 40 bytes of memory. The global pointer has static storage duration.
// We do not change the pointer, so the respective memory will
// be still reachable by the end of program lifetime
still_reachable = malloc(40 * sizeof *still_reachable);
} // scope of definitely_lost_local ends here --> 10 bytes are lost!
We can guess that 10+20 = 30 bytes will be lost in this example, while 40 bytes will be still reachable. So let's check with valgrind:
==19474== Memcheck, a memory error detector
==19474== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19474== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==19474== Command: ./prog
==19474==
==19474==
==19474== HEAP SUMMARY:
==19474== in use at exit: 70 bytes in 3 blocks
==19474== total heap usage: 3 allocs, 0 frees, 70 bytes allocated
==19474==
==19474== LEAK SUMMARY:
==19474== definitely lost: 30 bytes in 2 blocks
==19474== indirectly lost: 0 bytes in 0 blocks
==19474== possibly lost: 0 bytes in 0 blocks
==19474== still reachable: 40 bytes in 1 blocks
==19474== suppressed: 0 bytes in 0 blocks
==19474== Rerun with --leak-check=full to see details of leaked memory
==19474==
==19474== For counts of detected and suppressed errors, rerun with: -v
==19474== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Voilá, as expected.
Hi my Valgrind shows me memory error but I cant find it.
==18608== HEAP SUMMARY:
==18608== in use at exit: 88 bytes in 1 blocks
==18608== total heap usage: 4 allocs, 3 frees, 2,220 bytes allocated
==18608==
==18608== Searching for pointers to 1 not-freed blocks
==18608== Checked 53,708 bytes
==18608==
==18608== 88 bytes in 1 blocks are definitely lost in loss record 1 of 1
==18608== at 0x402D17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18608== by 0x8
0485BF: pmalloc (in auf)
==18608== by 0x8048680: main (in auf)
==18608==
==18608== LEAK SUMMARY:
==18608== definitely lost: 88 bytes in 1 blocks
==18608== indirectly lost: 0 bytes in 0 blocks
==18608== possibly lost: 0 bytes in 0 blocks
==18608== still reachable: 0 bytes in 0 blocks
==18608== suppressed: 0 bytes in 0 blocks
==18608==
==18608== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==18608== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
You allocate two different int *s; you don't free the first resource but you free the second one without doing anything with it:
print_prim(pmalloc(n), laenge);
free(pmalloc(laenge));
To free the first resource properly, you would do something like this:
int *p = pmalloc(n);
print_prim(p, laenge);
free(p);
I was just testing out some c code I was writing and I found that I had a lot of memory leaks, so I wanted to see where they were coming from. All the code I had was:
int main() {
return 0;
}
Just a simple main that did nothing and I had all these memory leaks:
==38882== HEAP SUMMARY:
==38882== in use at exit: 58,678 bytes in 363 blocks
==38882== total heap usage: 514 allocs, 151 frees, 62,544 bytes allocated
==38882==
==38882== LEAK SUMMARY:
==38882== definitely lost: 8,624 bytes in 14 blocks
==38882== indirectly lost: 1,168 bytes in 5 blocks
==38882== possibly lost: 4,925 bytes in 68 blocks
==38882== still reachable: 43,961 bytes in 276 blocks
==38882== suppressed: 0 bytes in 0 blocks
==38882== Rerun with --leak-check=full to see details of leaked memory
==38882==
==38882== For counts of detected and suppressed errors, rerun with: -v
==38882== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
When I run this code on my university's computers I have no memory leaks. Is there something on my local machine that is causing this many memory leaks?
It is fine. Your program uses runtime library (i.e. libc or equivalent) and the library allocates some memory for own needs.
I get the same error on my Mac. It's either a valgrind problem or (more likely) a library problem on the Mac. I would suggest to use valgrind only on Linux.
I am profiling my source. I see some allocations that are still alive at exit when I run valgrind.
Here is the summary:
$ valgrind --track-origins=yes --show-reachable=yes --leak-check=full $BINARY
...
==20235== LEAK SUMMARY:
==20235== definitely lost: 0 bytes in 0 blocks
==20235== indirectly lost: 0 bytes in 0 blocks
==20235== possibly lost: 0 bytes in 0 blocks
==20235== still reachable: 20,228 bytes in 37 blocks
==20235== suppressed: 0 bytes in 0 blocks
==20235==
The responsible libraries are:
dyld: all 81 mallocs have common calls as: (no clue)
{libsystem_c, libsystem_notify, libdispatch}.dylib: all 10 mallocs have common calls as:
localtime(...) defined in time.h uses tzset(...) to initialize and return me
a struct tm* which I shouldn't free myself because I did not allocate it.
How do I recover these 20,228 bytes which are still reachable?
UPDATE
I am running Mac OS X
I've used valgrind before and it has been very helpful. I recently setup a dev environment and starting using valgrind again. This time it finds NO lost memory! Even if I malloc some memory and then interrupt the program with CTRL-C, I get the dump below. Can someone explain what's going on?
Confused....
==2489== HEAP SUMMARY:
==2489== in use at exit: 314,145 bytes in 585 blocks
==2489== total heap usage: 1,410 allocs, 825 frees, 2,025,829 bytes allocated
==2489==
==2489== LEAK SUMMARY:
==2489== definitely lost: 0 bytes in 0 blocks
==2489== indirectly lost: 0 bytes in 0 blocks
==2489== possibly lost: 0 bytes in 0 blocks
==2489== still reachable: 314,145 bytes in 585 blocks
==2489== suppressed: 0 bytes in 0 blocks
==2489== Reachable blocks (those to which a pointer was found) are not shown.
==2489== To see them, rerun with: --leak-check=full --show-reachable=yes
==2489==
==2489== For counts of detected and suppressed errors, rerun with: -v
==2489== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
If there is still a pointer to the malloced memory, it's not a leak. It's showing up as still reachable in the summary.
Memory that is not freeed is not necessarily leaked if it's still live, that is, there's still a pointer to it somewhere (globally, from the stack, or from registers.)