Is valgrind memcheck false positive?

Question

Here is my code.

#include <stdio.h> #include <stdlib.h> #include <string.h> char buf1[100]; char buf2[100]; int main() { char **p = (char**)(buf1+sizeof(long)); char **q = (char**)(buf2+1); *p = (char*)malloc(100); *q = (char*)malloc(100); strcpy(*p, "xxxx"); strcpy(*q, "zzzz"); printf("p:%sq:%s\n", *p, *q); return 0; } 

I compiled the code using gcc and ran valgrind-3.6.1 like this

 valgrind --leak-check=full --log-file=test.log --show-reachable=yes ~/a.out 

valgrind gave me the log below

 ==20768== Memcheck, a memory error detector ==20768== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==20768== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==20768== Command: /home/zxin11/a.out ==20768== Parent PID: 12686 ==20768== ==20768== ==20768== HEAP SUMMARY: ==20768== in use at exit: 200 bytes in 2 blocks ==20768== total heap usage: 2 allocs, 0 frees, 200 bytes allocated ==20768== ==20768== 100 bytes in 1 blocks are still reachable in loss record 1 of 2 ==20768== at 0x4C2488B: malloc (vg_replace_malloc.c:236) ==20768== by 0x4005FD: main (test2.c:12) ==20768== ==20768== 100 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==20768== at 0x4C2488B: malloc (vg_replace_malloc.c:236) ==20768== by 0x400611: main (test2.c:13) ==20768== ==20768== LEAK SUMMARY: ==20768== definitely lost: 100 bytes in 1 blocks ==20768== indirectly lost: 0 bytes in 0 blocks ==20768== possibly lost: 0 bytes in 0 blocks ==20768== still reachable: 100 bytes in 1 blocks ==20768== suppressed: 0 bytes in 0 blocks ==20768== ==20768== For counts of detected and suppressed errors, rerun with: -v ==20768== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 3) 

Why was the first malloc still available and the second malloc definitely lost? Maybe this concerns alignment, you cannot put the malloced memory address in an un-aligned variable, if so, how can I suppress this positive report? Think you are very.

Answer 1

From the memcheck manual (my attention):

If --leak-check set appropriately, for each remaining block, Memcheck determines whether the block is accessible from the pointers in the root set. The root set consists of (a) general registers for all threads and (b) initialized, aligned, pointer-sized data words in available client memory, including stacks.

So your alignment hypothesis was correct. Unfortunately, the best way to correctly suppress such a warning is to probably just copy any such known values ​​to aligned locations before exiting your program (presumably this code is a layout for your real application, where it makes some sense for you to store unaligned pointers).

You can also try writing or creating a suppression file with --gen-suppressions=yes . But if your application is not deterministic or you run it with different input data, this approach will be quite annoying.