New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3392 - valgrind: does not detect obvious memory leak #8255
Comments
jow-: Works for me:
In order for valgrind to be able to wrap malloc/free etc, you need an unstripped musl libc. To avoid doing a new build you could scp the unstripped libc.so to your target and execute it directly:
jow@j7:~/devel/lede/staging.git$ scp build_dir/toolchain-x86_64_gcc-8.4.0_musl/musl-1.1.24/lib/libc.so root@192.168.1.1:/tmp/
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
libc.so 100% 3811KB 9.8MB/s 00:00
jow@j7:~/devel/lede/staging.git$ ssh root@192.168.1.1
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
|
MikePetullo:
I am running valgrind on OpenWrt trunk x86_64. The package provides valgrind 3.15.0. My OpenWrt install also makes use of musl.
I have the following test program, which has an obvious memory leak:
#include <stdio.h>
#include <stdlib.h>
int f(void) {
char *buf = malloc(BUFSIZ);
if (buf == NULL) {
return -1;
}
return 0;
}
int main(void)
{
f();
}
Running valgrind on OpenWrt produces this:
valgrind --leak-check=full ./leak
==22148== Memcheck, a memory error detector
==22148== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22148== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==22148== Command: ./leak
==22148==
==22148== Conditional jump or move depends on uninitialised value(s)
==22148== at 0x4019DDC: ??? (in /lib/libc.so)
==22148== by 0x405AE5D: ??? (in /lib/libc.so)
==22148==
==22148== Conditional jump or move depends on uninitialised value(s)
==22148== at 0x401961F: ??? (in /lib/libc.so)
==22148== by 0x405AE5D: ??? (in /lib/libc.so)
==22148==
==22148==
==22148== HEAP SUMMARY:
==22148== in use at exit: 0 bytes in 0 blocks
==22148== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==22148==
==22148== All heap blocks were freed -- no leaks are possible
==22148==
==22148== Use --track-origins=yes to see where uninitialised values come from
==22148== For lists of detected and suppressed errors, rerun with: -s
==22148== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
There is no mention of the memory leak.
Here is the output I expect, as produced by running valgrind on Fedora:
valgrind --leak-check=full ./leak
==7325== Memcheck, a memory error detector
==7325== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7325== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==7325== Command: ./leak
==7325==
==7325==
==7325== HEAP SUMMARY:
==7325== in use at exit: 8,192 bytes in 1 blocks
==7325== total heap usage: 1 allocs, 0 frees, 8,192 bytes allocated
==7325==
==7325== 8,192 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7325== at 0x483A809: malloc (vg_replace_malloc.c:307)
==7325== by 0x401137: f (leak.c:5)
==7325== by 0x401159: main (leak.c:14)
==7325==
==7325== LEAK SUMMARY:
==7325== definitely lost: 8,192 bytes in 1 blocks
==7325== indirectly lost: 0 bytes in 0 blocks
==7325== possibly lost: 0 bytes in 0 blocks
==7325== still reachable: 0 bytes in 0 blocks
==7325== suppressed: 0 bytes in 0 blocks
==7325==
==7325== For lists of detected and suppressed errors, rerun with: -s
==7325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
The text was updated successfully, but these errors were encountered: