问题
I have been looking at debugging the memory usage in a forking TCP server. I think I am doing pretty well, I just can't seem to find information on the 'bytes allocated' number in the 'heap summary'. This number seems to be ever increasing the longer my server runs:
==27526==
==27526== HEAP SUMMARY:
==27526== in use at exit: 0 bytes in 0 blocks
==27526== total heap usage: 113 allocs, 113 frees, 283,043 bytes allocated
==27526==
==27526== All heap blocks were freed -- no leaks are possible
==27526==
==27526== For counts of detected and suppressed errors, rerun with: -v
==27526== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
==27528==
==27528== HEAP SUMMARY:
==27528== in use at exit: 0 bytes in 0 blocks
==27528== total heap usage: 120 allocs, 120 frees, 300,808 bytes allocated
==27528==
==27528== All heap blocks were freed -- no leaks are possible
==27528==
==27528== For counts of detected and suppressed errors, rerun with: -v
==27528== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
==27537==
==27537== HEAP SUMMARY:
==27537== in use at exit: 0 bytes in 0 blocks
==27537== total heap usage: 127 allocs, 127 frees, 318,573 bytes allocated
==27537==
==27537== All heap blocks were freed -- no leaks are possible
==27537==
==27537== For counts of detected and suppressed errors, rerun with: -v
==27537== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Although Valgrind reports allocs and free are equal and no leaks are possible I do not trust the allocated bytes increasing.
So : if the bytes allocated keeps increasing does this mean I have to deallocate from the heap somewhere even if Valgrind reports no leaks are possible?
Thanks!
EDIT: With Gordon Bailey's answer and the other tips I am still a bit weary. Wrote this little app:
/* client.c */
#include <stdio.h>
void child_func(int childnum);
int main(int argc, char *argv[])
{
int nchildren = 1;
int pid;
int x;
if (argc > 1)
{
nchildren = atoi(argv[1]);
}
for (x = 0; x < nchildren; x++)
{
if ((pid = fork()) == 0)
{
child_func(x + 1);
exit(0);
}
}
wait(NULL);
return 0;
}
void child_func(int childnum)
{
int i;
for (i = 0; i < 1000; i++) {
free(malloc(1));
}
sleep(1);
}
When I run this the Valgrind output is:
==28245== HEAP SUMMARY:
==28245== in use at exit: 0 bytes in 0 blocks
==28245== total heap usage: 1,000 allocs, 1,000 frees, 1,000 bytes allocated
==28245==
==28245== All heap blocks were freed -- no leaks are possible
==28245==
==28245== For counts of detected and suppressed errors, rerun with: -v
==28245== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
==28246== HEAP SUMMARY:
==28246== in use at exit: 0 bytes in 0 blocks
==28246== total heap usage: 1,000 allocs, 1,000 frees, 1,000 bytes allocated
==28246==
==28246== All heap blocks were freed -- no leaks are possible
So it looks like all memory is cleared on the heap and is definitely different from the output of my app.
回答1:
Valgrind's bytes allocated is the total number of bytes you've allocated over the runtime of the process.
If you compile and run this weird little test program:
#include <stdio.h>
#include <stdlib.h>
int main()
{
int i;
for(i = 0; i < 1000; ++i){
free(malloc(1));
}
return 0;
}
Valgrind's output is:
==2651== Memcheck, a memory error detector
==2651== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2651== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==2651== Command: ./test_prog
==2651==
==2651==
==2651== HEAP SUMMARY:
==2651== in use at exit: 0 bytes in 0 blocks
==2651== total heap usage: 1,000 allocs, 1,000 frees, 1,000 bytes allocated
==2651==
==2651== All heap blocks were freed -- no leaks are possible
==2651==
==2651== For counts of detected and suppressed errors, rerun with: -v
==2651== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
It seems like the real question now is how child processes affect this.
(edited to confirm what I thought)
回答2:
It is simply the sum of the sizes to all your malloc (and similar) calls. If you've free'd that, which valgrind says you have, there's no problem. i.e. your proces 27526 did 113 allocs for a total of 283,043 bytes,
If your server keeps allocating memory, that number goes up, calling free() does not decrease that number.
回答3:
as Godron said, valgrind output all memory allocation in the current process:
toc@UnixServer:~$ valgrind --leak-check=full ./pb_valgrind
==11411== Memcheck, a memory error detector
==11411== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==11411== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==11411== Command: ./pb_valgrind
==11411==
==11414==
==11414== HEAP SUMMARY:
==11414== in use at exit: 0 bytes in 0 blocks
==11414== total heap usage: 1,000 allocs, 1,000 frees, 1,000 bytes allocated
==11414==
==11414== All heap blocks were freed -- no leaks are possible
==11414==
==11414== For counts of detected and suppressed errors, rerun with: -v
==11414== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6)
==11411==
==11411== HEAP SUMMARY:
==11411== in use at exit: 0 bytes in 0 blocks
==11411== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==11411==
==11411== All heap blocks were freed -- no leaks are possible
==11411==
==11411== For counts of detected and suppressed errors, rerun with: -v
==11411== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6)
In your program, you do 1000 mallocs of size 1 byte then 1000 free, which explain the output.
Regards.
回答4:
I think the problem is that when I run the application the number of frees and allocs increases each loop. This is causing the bytes allocated number to become bigger as each time the alloc actually assigns more memory as there are more actual allocs.
Not sure why that is happening, but it must be my buggy code and should be in another question.
Thanks for the help!
来源：https://stackoverflow.com/questions/11730265/valgrind-understanding-bytes-allocated-increase-in-heap-summary