开发者

valgrind memcheck reports false positive?

开发者 https://www.devze.com 2023-02-12 18:32 出处:网络
Here\'s my code. #include <stdio.h> #include <stdlib.h> #include <string.h> char buf1[100];

Here's 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:%s   q:%s\n", *p, *q);
    return 0;
}

I compiled the code using gcc, and run 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 the first malloc was still reachable while the second malloc was definitely lost? Maybe it's about alignment, you can't put the address of malloced memory into an un-aligned variable, if so, how can I suppress this kind of positive report? Think you very much.


From the memcheck manual (emphasis mine):

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

So your conjecture about alignment was correct. Unfortunately, the best way to robustly suppress such a warning is probably just to copy any such known values into aligned locations before exiting your program (presumably this code is a mock-up for your real application, where it makes some sort of sense for you to store unaligned pointers).

You can also try writing or generating a suppression file with --gen-suppressions=yes. But if your application is non-deterministic or you run it with different input data, this approach will get annoying pretty quickly.

0

精彩评论

暂无评论...
验证码 换一张
取 消