This question already has answers here:
Valgrind showing memory leak for printf and unused blocks
(2 answers)
Valgrind reports errors for a very simple C program
(3 answers)
Closed 6 years ago.
This simple program
///test.c
#include <stdio.h>
int main(){
double d = 13.37;
char buf[128];
snprintf(buf, 128, "%f", d);
return 0;
}
is leaking memory according to valgrind, the valgrind output when run
with --leak-check=full is
==29114== Memcheck, a memory error detector
==29114== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==29114== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==29114== Command: ./test
==29114==
==29114==
==29114== HEAP SUMMARY:
==29114== in use at exit: 22,175 bytes in 187 blocks
==29114== total heap usage: 263 allocs, 76 frees, 28,271 bytes allocated
==29114==
==29114== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 43 of 66
==29114== at 0x100008EBB: malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29114== by 0x1001C34A2: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x1001C3DEB: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x1001C0443: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x1001E907A: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x10021235C: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x1001F65A8: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x1001F665D: vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x100227CBF: __snprintf_chk (in /usr/lib/system/libsystem_c.dylib)
==29114== by 0x100000F4B: main (in ./test)
==29114==
==29114== LEAK SUMMARY:
==29114== definitely lost: 80 bytes in 1 blocks
==29114== indirectly lost: 68 bytes in 2 blocks
==29114== possibly lost: 0 bytes in 0 blocks
==29114== still reachable: 0 bytes in 0 blocks
==29114== suppressed: 22,027 bytes in 184 blocks
==29114==
==29114== For counts of detected and suppressed errors, rerun with: -v
==29114== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 18 from 18)
Either I'm misunderstanding something or snprintf seems to be leaking.
I'm on os x if it matters.
Edit: im interested in the "definitely lost" and "indirectly lost" memory leak not the suppressed memory (which isn't a leak).
Related
First, I have ran valgrind to make sure that (on the default settings) there are zero errors. Then, I decided to check for leaks with something like: --leak-check=full
I have code that looks something like char* variable=malloc(sizeof(char)*(strlen(in)+1)); and valgrind reports that memory is "definitely lost."
The only other line of code I have access to (this is in a library callback function) is the line of code where in is declared. This is a function argument of type void * (though in this case I'm hoping we can safely assume the value to be null terminated.)
Having
#include <stdlib.h>
char * G;
int main()
{
char * l = malloc(10);
G = malloc(20);
}
The execution under valgrind gives :
pi#raspberrypi:/tmp $ valgrind --leak-check=full ./a.out
==11087== Memcheck, a memory error detector
==11087== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11087== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11087== Command: ./a.out
==11087==
==11087==
==11087== HEAP SUMMARY:
==11087== in use at exit: 30 bytes in 2 blocks
==11087== total heap usage: 2 allocs, 0 frees, 30 bytes allocated
==11087==
==11087== 10 bytes in 1 blocks are definitely lost in loss record 1 of 2
==11087== at 0x4847568: malloc (vg_replace_malloc.c:299)
==11087== by 0x10453: main (mm.c:7)
==11087==
==11087== LEAK SUMMARY:
==11087== definitely lost: 10 bytes in 1 blocks
==11087== indirectly lost: 0 bytes in 0 blocks
==11087== possibly lost: 0 bytes in 0 blocks
==11087== still reachable: 20 bytes in 1 blocks
==11087== suppressed: 0 bytes in 0 blocks
==11087== Reachable blocks (those to which a pointer was found) are not shown.
==11087== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11087==
==11087== For counts of detected and suppressed errors, rerun with: -v
==11087== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 3)
The malloc(10) is definitely lost because there is no way to access it at the end of the execution (here out of main)
The malloc(20) is not lost because still reachable through G
I'm sorry if i eventually do something wrong.
Ok my problem is the following:
I just coded something very easy, but when you take a look at the Valgrind error output it just confuses me.
Code:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
int num1 = 100;
double num2 = 1.2;
printf("Number 1 one is: %d.\n Number two is: %f.\n", num1, num2);
return 0;
}
Valgrind error report:
$ valgrind --leak-check=full ./yaq
==50642== Memcheck, a memory error detector
==50642== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==50642== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==50642== Command: ./yaq
==50642==
--50642-- ./yaq:
--50642-- dSYM directory has wrong UUID; consider using --dsymutil=yes
==50642== Conditional jump or move depends on uninitialised value(s)
==50642== at 0x1003FCC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==50642== by 0x1001F0B96: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001FAFE5: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1002209AE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x100220C80: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001F6B71: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x1001F49D7: printf (in /usr/lib/system/libsystem_c.dylib)
==50642== by 0x100000F32: main (in ./yaq)
==50642==
Number 1 one is: 100.
Number two is: 1.200000.
==50642==
==50642== HEAP SUMMARY:
==50642== in use at exit: 38,673 bytes in 427 blocks
==50642== total heap usage: 510 allocs, 83 frees, 44,945 bytes.
==50642== To see them, rerun with: --leak-check=full --show-leak- kinds=all
==50642==
==50642== For counts of detected and suppressed errors, rerun with: -v
==50642== Use --track-origins=yes to see where uninitialised values come from
==50642== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 17 from 17)
Why does it say 3 errors ?
Thanks in advance.
Best regards
You may be able to see them if you run with --show-leak-kinds=all:
==96034== Memcheck, a memory error detector
==96034== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==96034== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==96034== Command: ./yaq
==96034==
--96034-- ./yaq:
--96034-- dSYM directory is missing; consider using --dsymutil=yes
==96034== Conditional jump or move depends on uninitialised value(s)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== 80 bytes in 1 blocks are still reachable in loss record 48 of 85
==96034== at 0x10000859B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==96034== by 0x1001D1756: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001D2075: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001CE88B: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F6D72: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== 4,096 bytes in 1 blocks are still reachable in loss record 85 of 85
==96034== at 0x10000859B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==96034== by 0x1001F0856: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1002053A7: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021F77D: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==96034== by 0x100000F32: main (in ./yaq)
==96034==
==96034== LEAK SUMMARY:
==96034== definitely lost: 0 bytes in 0 blocks
==96034== indirectly lost: 0 bytes in 0 blocks
==96034== possibly lost: 0 bytes in 0 blocks
==96034== still reachable: 4,244 bytes in 4 blocks
==96034== suppressed: 34,783 bytes in 425 blocks
==96034==
==96034== For counts of detected and suppressed errors, rerun with: -v
==96034== Use --track-origins=yes to see where uninitialised values come from
==96034== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 18 from 18)
Those are issues in the OS X system libraries. I suppressed them by generating this suppressions file with valgrind --leak-check=yes --show-leak-kinds=all --gen-suppressions=yes ./yaq. The output is a bit cleaner then:
$ valgrind --leak-check=yes --show-leak-kinds=all --suppressions=yaq.supp ./yaq [7:47:49]
==96285== Memcheck, a memory error detector
==96285== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==96285== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==96285== Command: ./yaq
==96285==
--96285-- ./yaq:
--96285-- dSYM directory is missing; consider using --dsymutil=yes
Number 1 one is: 100.
Number two is: 1.200000.
==96285==
==96285== HEAP SUMMARY:
==96285== in use at exit: 39,027 bytes in 429 blocks
==96285== total heap usage: 510 allocs, 81 frees, 45,171 bytes allocated
==96285==
==96285== LEAK SUMMARY:
==96285== definitely lost: 0 bytes in 0 blocks
==96285== indirectly lost: 0 bytes in 0 blocks
==96285== possibly lost: 0 bytes in 0 blocks
==96285== still reachable: 0 bytes in 0 blocks
==96285== suppressed: 39,027 bytes in 429 blocks
==96285==
==96285== For counts of detected and suppressed errors, rerun with: -v
==96285== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 19)
Valgrind support on OS X is currently being actively worked on. Your best approach is to ensure you are using a SVN trunk build, and update frequently.
The errors Valgrind is reporting to you are present within the OS X system libraries. These are not the fault of your program, but because even simple programs including these system libraries Valgrind continues to pick them up. Suppressions within Valgrind trunk are continually being updated to catch these issues, allowing you to focus on the real problems that may be present within your code.
The following commands will allow you to use Valgrind trunk, if you're not already:
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure
make -j4
sudo make install
Valgrind reports definitely lost memory if I exit main with return 0;, but reports still reachable memory if I exit main with exit(0);.
test-reachable.c:
#include <stdlib.h>
int main() {
void *data = malloc(256);
exit(0);
}
test-lost.c:
#include <stdlib.h>
int main() {
void *data = malloc(256);
return 0;
}
Behavior:
$ gcc test-reachable.c -o test-reachable
$ valgrind --leak-check=yes ./test-reachable
==7696== Memcheck, a memory error detector
==7696== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7696== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7696== Command: ./test-reachable
==7696==
==7696==
==7696== HEAP SUMMARY:
==7696== in use at exit: 256 bytes in 1 blocks
==7696== total heap usage: 1 allocs, 0 frees, 256 bytes allocated
==7696==
==7696== LEAK SUMMARY:
==7696== definitely lost: 0 bytes in 0 blocks
==7696== indirectly lost: 0 bytes in 0 blocks
==7696== possibly lost: 0 bytes in 0 blocks
==7696== still reachable: 256 bytes in 1 blocks
==7696== suppressed: 0 bytes in 0 blocks
==7696== Reachable blocks (those to which a pointer was found) are not shown.
==7696== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7696==
==7696== For counts of detected and suppressed errors, rerun with: -v
==7696== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ gcc test-lost.c -o test-lost
$ valgrind --leak-check=yes ./test-lost
==7774== Memcheck, a memory error detector
==7774== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7774== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7774== Command: ./test-lost
==7774==
==7774==
==7774== HEAP SUMMARY:
==7774== in use at exit: 256 bytes in 1 blocks
==7774== total heap usage: 1 allocs, 0 frees, 256 bytes allocated
==7774==
==7774== 256 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7774== at 0x4C2C080: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7774== by 0x40051C: main (in /tmp/test-lost)
==7774==
==7774== LEAK SUMMARY:
==7774== definitely lost: 256 bytes in 1 blocks
==7774== indirectly lost: 0 bytes in 0 blocks
==7774== possibly lost: 0 bytes in 0 blocks
==7774== still reachable: 0 bytes in 0 blocks
==7774== suppressed: 0 bytes in 0 blocks
==7774==
==7774== For counts of detected and suppressed errors, rerun with: -v
==7774== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Shouldn't these behave the same?
Shouldn't these behave the same?
No.
In test-reachable.c the memory is referenced by the stack variable data at the time of the exit of the program, so it is still reachable, while in test-lost.c the memory is not referenced anymore because the main function has already returned, the reference does not exist anymore, the memory is definitely lost.
In C++ when return in main() is called then the destructors will be called for locally scoped objects whereas if exit() is called then no destructor will be called for locally scoped objects.
I think this is similar in C with regards to objects allocated on the stack.
That probably explains why in the return case non freed memory is treated as definitely lost and in the exit(0) case the memory is reported as still reachable.
This question already has answers here:
Valgrind reports errors for a very simple C program
(3 answers)
Closed 7 years ago.
The challenge is to clear all Valgrind errors before going on to the next lesson, but I don't really know what's wrong with this program. I want to know what's wrong before going on. Thanks, appreciate the help.
#include <stdio.h>
int main()
{
int age = 10;
int height = 72;
printf("I am %d years old.\n", age);
printf("I am %d inches tall.\n", height);
return 0;
}
Here's the valgrind report:
==41714== Memcheck, a memory error detector
==41714== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==41714== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==41714== Command: ./ex3
==41714==
==41714== Conditional jump or move depends on uninitialised value(s)
==41714== at 0x1003FBC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==41714== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==41714== by 0x100000F4D: main (ex3.c:8)
==41714==
I am 10 years old.
I am 72 inches tall.
==41714==
==41714== HEAP SUMMARY:
==41714== in use at exit: 38,816 bytes in 426 blocks
==41714== total heap usage: 507 allocs, 81 frees, 44,960 bytes allocated
==41714==
==41714== LEAK SUMMARY:
==41714== definitely lost: 0 bytes in 0 blocks
==41714== indirectly lost: 0 bytes in 0 blocks
==41714== possibly lost: 0 bytes in 0 blocks
==41714== still reachable: 4,096 bytes in 1 blocks
==41714== suppressed: 34,720 bytes in 425 blocks
==41714== Rerun with --leak-check=full to see details of leaked memory
==41714==
==41714== For counts of detected and suppressed errors, rerun with: -v
==41714== Use --track-origins=yes to see where uninitialised values come from
==41714== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
There are very clearly no memory issues. You never even malloc or free anything, so at this point all memory is handled without you being involved. This must be an issue with the Valgrind. If you are using OSX perhaps try on a machine with linux if you have one available.
Consider this code:
int main(int argc, char const *argv[])
{
char *string = NULL;
string = malloc(sizeof(char) * 30);
free(string);
return 0;
}
I malloc a char pointer then I free it after. Now consider the valgrind output:
==58317== Memcheck, a memory error detector
==58317== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==58317== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==58317== Command: ./a.out
==58317==
==58317==
==58317== HEAP SUMMARY:
==58317== in use at exit: 34,941 bytes in 424 blocks
==58317== total heap usage: 505 allocs, 81 frees, 41,099 bytes allocated
==58317==
==58317== LEAK SUMMARY:
==58317== definitely lost: 0 bytes in 0 blocks
==58317== indirectly lost: 0 bytes in 0 blocks
==58317== possibly lost: 0 bytes in 0 blocks
==58317== still reachable: 0 bytes in 0 blocks
==58317== suppressed: 34,941 bytes in 424 blocks
==58317==
==58317== For counts of detected and suppressed errors, rerun with: -v
==58317== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
How is it possible to have that many mallocs and frees?
Edit: This is what I get when I run with valgrind --leak-check=yes --gen-suppressions=all ./a.out, I am trying to make a supp file.
==60943== Memcheck, a memory error detector
==60943== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==60943== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==60943== Command: ./a.out
==60943==
==60943==
==60943== HEAP SUMMARY:
==60943== in use at exit: 34,941 bytes in 424 blocks
==60943== total heap usage: 505 allocs, 81 frees, 41,099 bytes allocated
==60943==
==60943== LEAK SUMMARY:
==60943== definitely lost: 0 bytes in 0 blocks
==60943== indirectly lost: 0 bytes in 0 blocks
==60943== possibly lost: 0 bytes in 0 blocks
==60943== still reachable: 0 bytes in 0 blocks
==60943== suppressed: 34,941 bytes in 424 blocks
==60943==
==60943== For counts of detected and suppressed errors, rerun with: -v
==60943== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)
Those blocks were allocated (and some of them freed as well) by a system library that was linked into your executable.
Valgrind has a default suppression file that suppresses leaks in system libraries, which is what you can see further in the output :
==58317== suppressed: 34,941 bytes in 424 blocks
If you want more details on what exactly was suppressed, you can use the -v option.