我在使用 valgrind 时遇到问题。在我的项目中,所有结构都被 #pragma pack(2) 包围以减少内存使用。
现在,将内存分配给结构中的指针会导致 valgrind 错误,例如。 g.: loss record 2 of 3 7 block 14 bytes肯定丢失。
编辑:我不够精确。当然,由于我从不调用 free,因此存在内存泄漏。但问题是,valgrind 说内存肯定丢失了。事实并非如此,因为 param_info 是静态的。
那么为什么 valgrind 说肯定丢失并且仍然无法访问?如果我删除 pragma 指令,则输出符合预期。
这是可以预料的吗?如果是这样,有人可以解释为什么吗?
这是重现错误的最小示例:
#include <stdlib.h>
#pragma pack(push)
#pragma pack(2)
struct param_ref
{
short *p;
short max_p;
};
#pragma pack(pop)
int main()
{
static struct param_ref *param_info = NULL;
static short param_max = 0;
int i;
if (param_info == NULL)
{
param_max = 10;
param_info = malloc(sizeof (struct param_ref) * param_max);
for (i = 0; i < param_max; i++)
{
param_info[i].p = malloc(sizeof (short));
param_info[i].max_p = 1;
}
}
return 0;
}
和 valgrind 输出:
xxx@homer:~/val$ valgrind --leak-check=full ./a.out
==4156== Memcheck, a memory error detector
==4156== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4156== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==4156== Command: ./a.out
==4156==
==4156==
==4156== HEAP SUMMARY:
==4156== in use at exit: 120 bytes in 11 blocks
==4156== total heap usage: 11 allocs, 0 frees, 120 bytes allocated
==4156==
==4156== 14 bytes in 7 blocks are definitely lost in loss record 2 of 3
==4156== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4156== by 0x4005AF: main (in /home/xxx/val/a.out)
==4156==
==4156== LEAK SUMMARY:
==4156== definitely lost: 14 bytes in 7 blocks
==4156== indirectly lost: 0 bytes in 0 blocks
==4156== possibly lost: 0 bytes in 0 blocks
==4156== still reachable: 106 bytes in 4 blocks
==4156== suppressed: 0 bytes in 0 blocks
==4156== Reachable blocks (those to which a pointer was found) are not shown.
==4156== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4156==
==4156== For counts of detected and suppressed errors, rerun with: -v
==4156== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
EDIT2:没有 pragma 指令的 valgrind 输出:
xxx@homer:~/val$ valgrind --leak-check=full ./a.out
==5374== Memcheck, a memory error detector
==5374== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5374== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==5374== Command: ./a.out
==5374==
==5374==
==5374== HEAP SUMMARY:
==5374== in use at exit: 180 bytes in 11 blocks
==5374== total heap usage: 11 allocs, 0 frees, 180 bytes allocated
==5374==
==5374== LEAK SUMMARY:
==5374== definitely lost: 0 bytes in 0 blocks
==5374== indirectly lost: 0 bytes in 0 blocks
==5374== possibly lost: 0 bytes in 0 blocks
==5374== still reachable: 180 bytes in 11 blocks
==5374== suppressed: 0 bytes in 0 blocks
==5374== Reachable blocks (those to which a pointer was found) are not shown.
==5374== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5374==
==5374== For counts of detected and suppressed errors, rerun with: -v
==5374== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
最佳答案
由于打包,一些指向内存的指针没有正确对齐以供 valgrind 找到它们,因此 valgrind 报告它们肯定丢失了。似乎没有像 LeakSanitizer 这样的选项:
LSAN_OPTIONS=use_unaligned=1
use_unaligned : If 0, LSan will only consider properly aligned 8-byte patterns when looking for pointers. Set to 1 to include unaligned patterns. This refers to the pointer itself, not the memory being pointed at.
$ gcc so.c -fsanitize=address -g
$ ./a.out
=================================================================
==4943==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 14 byte(s) in 7 object(s) allocated from:
#0 0x7fe18898ba0a in malloc (/lib64/libasan.so.2+0x98a0a)
#1 0x4008d2 in main /home/m/so.c:28
#2 0x7fe18855378f in __libc_start_main (/lib64/libc.so.6+0x2078f)
SUMMARY: AddressSanitizer: 14 byte(s) leaked in 7 allocation(s).
$ LSAN_OPTIONS=use_unaligned=1 ./a.out
$
关于c - Valgrind 和 "#pragma pack(2)",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33178242/