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: