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);
Related
I'm working on a system programming project that requires forking N process. The issue is I'm keeping the PID's in a dynamicly allocated array and valgrind with "--leak-check=full --show-leak-kinds=all" flags shows this PID array pointer as possible leak.
pid_t *pid;
//...globals & prototypes
int main(int argc, char *argv[])
{
//... Input parsing
// Create actor process=========================================
pid = malloc((_N + _V + _C + 1) * sizeof(pid_t *)); // LINE VALGRIND IS POINTING STILL REACHABLE
for (int i = 0; i < _N + _V + _C + 1; i++)
{
pid[i] = fork();
if (pid[i] == 0)
break;
}
// ======================================== Create actor process
// Parent process ====================================================
if (parent_pid == getpid())
{
// Wait for all the childeren=====================================
for (int i = 0; i < _N + _V + _C + 1 || exit_requested != 0; i++)
{
int status;
if (waitpid(pid[i], &status, 0) == -1)
{
errExit("waitpid");
}
}
// =====================================Wait for all the childeren
// Free resources
free(pid);
//.. destroy semaphores
shm_unlink(SHARED_LINK);
}
// Child processes ===================================================
else
{
for (int i = 0; i < _N + _V + _C + 1; i++)
{
if (i >= 0 && i < _N && pid[i] == 0)
{
producer(_I, shared_data, i);
}
else if (i >= _N && i < _N + _V && pid[i] == 0)
{
mid_consumer(shared_data, i - _N);
}
else if (i >= _N + _V && i < _N + _V + _C && pid[i] == 0)
{
end_consumer(shared_data, i - _N - _V);
}
}
}
// ===================================================================
return 0;
}
Here is the valgrind output
==8056== Memcheck, a memory error detector
==8056== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8056== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==8056== Command: ./program -n 2 -v 2 -c 4 -b 81 -t 2 -i cold_storage.txt
==8056== Parent PID: 8055
==8056==
==8061==
==8061== HEAP SUMMARY:
==8061== in use at exit: 72 bytes in 1 blocks
==8061== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8061==
==8061== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8061== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8061== by 0x10925D: main (main.c:169)
==8061==
==8061== LEAK SUMMARY:
==8061== definitely lost: 0 bytes in 0 blocks
==8061== indirectly lost: 0 bytes in 0 blocks
==8061== possibly lost: 0 bytes in 0 blocks
==8061== still reachable: 72 bytes in 1 blocks
==8061== suppressed: 0 bytes in 0 blocks
==8061==
==8061== For counts of detected and suppressed errors, rerun with: -v
==8061== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8059==
==8059== HEAP SUMMARY:
==8059== in use at exit: 72 bytes in 1 blocks
==8059== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8059==
==8057==
==8062==
==8057== HEAP SUMMARY:
==8057== in use at exit: 72 bytes in 1 blocks
==8057== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8057==
==8062== HEAP SUMMARY:
==8062== in use at exit: 72 bytes in 1 blocks
==8062== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8062==
==8059== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8059== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8059== by 0x10925D: main (main.c:169)
==8059==
==8059== LEAK SUMMARY:
==8059== definitely lost: 0 bytes in 0 blocks
==8059== indirectly lost: 0 bytes in 0 blocks
==8059== possibly lost: 0 bytes in 0 blocks
==8059== still reachable: 72 bytes in 1 blocks
==8059== suppressed: 0 bytes in 0 blocks
==8059==
==8059== For counts of detected and suppressed errors, rerun with: -v
==8059== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8062== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8057== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8062== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8057== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8062== by 0x10925D: main (main.c:169)
==8062==
==8057== by 0x10925D: main (main.c:169)
==8062== LEAK SUMMARY:
==8057==
==8062== definitely lost: 0 bytes in 0 blocks
==8057== LEAK SUMMARY:
==8062== indirectly lost: 0 bytes in 0 blocks
==8057== definitely lost: 0 bytes in 0 blocks
==8062== possibly lost: 0 bytes in 0 blocks
==8057== indirectly lost: 0 bytes in 0 blocks
==8062== still reachable: 72 bytes in 1 blocks
==8057== possibly lost: 0 bytes in 0 blocks
==8062== suppressed: 0 bytes in 0 blocks
==8057== still reachable: 72 bytes in 1 blocks
==8062==
==8057== suppressed: 0 bytes in 0 blocks
==8062== For counts of detected and suppressed errors, rerun with: -v
==8057==
==8062== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8057== For counts of detected and suppressed errors, rerun with: -v
==8057== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8063==
==8063== HEAP SUMMARY:
==8063== in use at exit: 72 bytes in 1 blocks
==8063== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8063==
==8063== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8063== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8063== by 0x10925D: main (main.c:169)
==8063==
==8063== LEAK SUMMARY:
==8063== definitely lost: 0 bytes in 0 blocks
==8063== indirectly lost: 0 bytes in 0 blocks
==8063== possibly lost: 0 bytes in 0 blocks
==8063== still reachable: 72 bytes in 1 blocks
==8063== suppressed: 0 bytes in 0 blocks
==8063==
==8063== For counts of detected and suppressed errors, rerun with: -v
==8063== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8058==
==8058== HEAP SUMMARY:
==8058== in use at exit: 72 bytes in 1 blocks
==8058== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8058==
==8058== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8058== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8058== by 0x10925D: main (main.c:169)
==8058==
==8058== LEAK SUMMARY:
==8058== definitely lost: 0 bytes in 0 blocks
==8058== indirectly lost: 0 bytes in 0 blocks
==8058== possibly lost: 0 bytes in 0 blocks
==8058== still reachable: 72 bytes in 1 blocks
==8058== suppressed: 0 bytes in 0 blocks
==8058==
==8058== For counts of detected and suppressed errors, rerun with: -v
==8058== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8064==
==8064== HEAP SUMMARY:
==8064== in use at exit: 72 bytes in 1 blocks
==8064== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8064==
==8064== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8064== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8064== by 0x10925D: main (main.c:169)
==8064==
==8064== LEAK SUMMARY:
==8064== definitely lost: 0 bytes in 0 blocks
==8064== indirectly lost: 0 bytes in 0 blocks
==8064== possibly lost: 0 bytes in 0 blocks
==8064== still reachable: 72 bytes in 1 blocks
==8064== suppressed: 0 bytes in 0 blocks
==8064==
==8064== For counts of detected and suppressed errors, rerun with: -v
==8064== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8060==
==8060== HEAP SUMMARY:
==8060== in use at exit: 72 bytes in 1 blocks
==8060== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8060==
==8060== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8060== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8060== by 0x10925D: main (main.c:169)
==8060==
==8060== LEAK SUMMARY:
==8060== definitely lost: 0 bytes in 0 blocks
==8060== indirectly lost: 0 bytes in 0 blocks
==8060== possibly lost: 0 bytes in 0 blocks
==8060== still reachable: 72 bytes in 1 blocks
==8060== suppressed: 0 bytes in 0 blocks
==8060==
==8060== For counts of detected and suppressed errors, rerun with: -v
==8060== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8065==
==8065== HEAP SUMMARY:
==8065== in use at exit: 72 bytes in 1 blocks
==8065== total heap usage: 1 allocs, 0 frees, 72 bytes allocated
==8065==
==8065== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==8065== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8065== by 0x10925D: main (main.c:169)
==8065==
==8065== LEAK SUMMARY:
==8065== definitely lost: 0 bytes in 0 blocks
==8065== indirectly lost: 0 bytes in 0 blocks
==8065== possibly lost: 0 bytes in 0 blocks
==8065== still reachable: 72 bytes in 1 blocks
==8065== suppressed: 0 bytes in 0 blocks
==8065==
==8065== For counts of detected and suppressed errors, rerun with: -v
==8065== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8056==
==8056== HEAP SUMMARY:
==8056== in use at exit: 0 bytes in 0 blocks
==8056== total heap usage: 1 allocs, 1 frees, 72 bytes allocated
==8056==
==8056== All heap blocks were freed -- no leaks are possible
==8056==
==8056== For counts of detected and suppressed errors, rerun with: -v
==8056== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I tried freeing the PID array in the forked processes too but it still gives the same error.
This is not a complete answer, but it addresses some concerns.
First, the pid array memory block is being allocated with the wrong size based on a multiple of sizeof(pid_t *) when it should be the same multiple of sizeof(pid_t). That is a harmless waste of memory if sizeof(pid_t *) is greater than sizeof(pid_t), but would be a buffer overrun in the unlike case that sizeof(pid_t *) is less than sizeof(pid_t).
Second, the child processes do not free the pid array memory block.
Third, the child processes loop through all the elements of the pid array memory block looking for pid[i] == 0. I believe this is the child process trying to find its own index. However, the pid array memory block has not been fully initialized in the child process fork, so there could be more than one element with the value 0. Besides, there is no need for the child process to use the pid array at all if all it needs is its index number which it can determine at the time of the fork().
The version below fixes those issues, but I don't know if it fixes the Valgrind errors.
pid_t *pid;
//...globals & prototypes
int main(int argc, char *argv[])
{
int cid; // child index
//... Input parsing
// Create actor process=========================================
pid = malloc((_N + _V + _C + 1) * sizeof(pid_t));
for (cid = 0; xid < _N + _V + _C + 1; cid++)
{
pid[cid] = fork();
if (pid[cid] == 0)
{
free(pid);
break;
}
}
// ======================================== Create actor process
// Parent process ====================================================
if (parent_pid == getpid())
{
// Wait for all the childeren=====================================
for (int i = 0; i < _N + _V + _C + 1 || exit_requested != 0; i++)
{
int status;
if (waitpid(pid[i], &status, 0) == -1)
{
errExit("waitpid");
}
}
// =====================================Wait for all the childeren
// Free resources
free(pid);
//.. destroy semaphores
shm_unlink(SHARED_LINK);
}
// Child processes ===================================================
else
{
if (cid >= 0 && cid < _N)
{
producer(_I, shared_data, cid);
}
else if (cid >= _N && cid < _N + _V)
{
mid_consumer(shared_data, cid - _N);
}
else if (cid >= _N + _V && cid < _N + _V + _C)
{
end_consumer(shared_data, cid - _N - _V);
}
}
// ===================================================================
return 0;
}
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.
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.
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]){
char *str = malloc(sizeof(char)*5);
str = strcpy(str, "test");
printf("%s\n", str);
free(str);
return 0;
}
When I use Valgrind on my Mac (OS X, 10.9.5) I get the following message:
==77215== HEAP SUMMARY:
==77215== in use at exit: 29,211 bytes in 374 blocks
==77215== total heap usage: 451 allocs, 77 frees, 35,160 bytes allocated
==77215==
==77215== 4,096 bytes in 1 blocks are still reachable in loss record 76 of 76
==77215== at 0x66CB: malloc (in /usr/local/Cellar/valgrind/3.10.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==77215== by 0x182855: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x197217: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x1B0158: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x1B06AF: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x187B29: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x18596F: printf (in /usr/lib/system/libsystem_c.dylib)
==77215== by 0x100000F2B: main (test.c:8)
==77215==
==77215== LEAK SUMMARY:
==77215== definitely lost: 0 bytes in 0 blocks
==77215== indirectly lost: 0 bytes in 0 blocks
==77215== possibly lost: 0 bytes in 0 blocks
==77215== still reachable: 4,096 bytes in 1 blocks
==77215== suppressed: 25,115 bytes in 373 blocks
==77215==
==77215== For counts of detected and suppressed errors, rerun with: -v
==77215== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)
Does printf allocate memory by itself? If I remove the printf I only get the following:
==77237== HEAP SUMMARY:
==77237== in use at exit: 25,115 bytes in 373 blocks
==77237== total heap usage: 450 allocs, 77 frees, 31,064 bytes allocated
==77237==
==77237== LEAK SUMMARY:
==77237== definitely lost: 0 bytes in 0 blocks
==77237== indirectly lost: 0 bytes in 0 blocks
==77237== possibly lost: 0 bytes in 0 blocks
==77237== still reachable: 0 bytes in 0 blocks
==77237== suppressed: 25,115 bytes in 373 blocks
==77237==
==77237== For counts of detected and suppressed errors, rerun with: -v
==77237== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)
Where does the 373 blocks come from?
Until the Valgrind team prioritizes OS X, you can safely assume that it will not give correct results on Apple systems running OS X versions newer than 10.7.
On my Mavericks (10.9.5) machine, I still get the following warning from Valgrind (3.9.0)
WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.
For what it's worth, Valgrind 3.10.0 shows no leaks on my Debian Jessie installation.
It isn't telling you that there is a leak:
==77215== LEAK SUMMARY:
==77215== definitely lost: 0 bytes in 0 blocks
==77215== indirectly lost: 0 bytes in 0 blocks
==77215== possibly lost: 0 bytes in 0 blocks
==77215== still reachable: 4,096 bytes in 1 blocks
==77215== suppressed: 25,115 bytes in 373 blocks
it's telling you that there is a block which is still reachable; whether or not there is a leak is dependent on your definition of 'leak'. What it does mean is that there is a pointer to the block somewhere.
Refer to Still Reachable Leak detected by Valgrind for more information.
I have the following code, and for some reason valgrind finds some memory leaks in the getlogin() function.
The code:
#include<unistd.h>
#include<stdio.h>
int main()
{
char *userName = getlogin();
printf("%s\n",userName);
return 0;
}
The valgrind command which I use:
valgrind --leak-check=full -v ./
The error I get:
HEAP SUMMARY:
==2405== in use at exit: 300 bytes in 11 blocks
==2405== total heap usage: 67 allocs, 56 frees, 9,106 bytes allocated
==2405==
==2405== Searching for pointers to 11 not-freed blocks
==2405== Checked 72,264 bytes
==2405==
==2405== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11
==2405== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2405== by 0x4F37CD4: nss_parse_service_list (nsswitch.c:678)
==2405== by 0x4F38795: __nss_database_lookup (nsswitch.c:175)
==2405== by 0x55F6623: ???
==2405== by 0x4EF144C: getpwuid_r##GLIBC_2.2.5 (getXXbyYY_r.c:256)
==2405== by 0x4F145AE: __getlogin_r_loginuid (getlogin_r.c:68)
==2405== by 0x4F14304: getlogin (getlogin.c:35)
==2405== by 0x400550: main (tmp1.c:6)
==2405==
==2405== LEAK SUMMARY:
==2405== definitely lost: 60 bytes in 1 blocks
==2405== indirectly lost: 240 bytes in 10 blocks
==2405== possibly lost: 0 bytes in 0 blocks
==2405== still reachable: 0 bytes in 0 blocks
==2405== suppressed: 0 bytes in 0 blocks
==2405==
==2405== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--2405--
--2405-- used_suppression: 2 dl-hack3-cond-1
==2405==
==2405== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Why does it happen? And what can I do to free it? Is there any other option to get the user name? Thanks in advance.
With valgrind 3.10.0 I have no error
==27656==
==27656== HEAP SUMMARY:
==27656== in use at exit: 0 bytes in 0 blocks
==27656== total heap usage: 67 allocs, 67 frees, 9,101 bytes allocated
==27656==
==27656== All heap blocks were freed -- no leaks are possible
==27656==
==27656== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==27656== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)>
Try to upgrade it or call __libc_freeres() after getlogin()
But there is no error in your programme, this type of memory leak is acceptable.