为什么 valgrind 在调用 `pcap_open_offline` 时会报告内存泄漏?
Why does valgrind report a memory leak when calling `pcap_open_offline`?
我想弄清楚我是否遇到了白痴,或者 libpcap 中是否真的存在内存泄漏。我是 运行 Ubuntu 17.10 和 libpcap 1.8.1-5ubuntu1。这么成熟的库,好像不太可能出现漏洞。
我已经删除了所有内容来制作 MVCE,因此,除了演示泄漏之外,这段代码实际上并没有做太多事情:
#include <stdio.h>
#include <stdlib.h>
#include <pcap.h>
int main(int argc, char **argv)
{
char errbuf[PCAP_ERRBUF_SIZE];
pcap_t *fd = pcap_open_offline(argv[1], errbuf);
if (!fd) {
printf("error: %s\n", errbuf);
}
free(fd); fd = 0;
return 0;
}
valgrind 报告(强调已添加):
==6871==
==6871== HEAP SUMMARY:
==6871== in use at exit: 262,696 bytes in 2 blocks
==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
==6871==
==6871== Searching for pointers to 2 not-freed blocks
==6871== Checked 73,072 bytes
==6871==
==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
<b>==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x1087A0: main (test.c:9)</b>
==6871==
==6871== LEAK SUMMARY:
==6871== definitely lost: 262,144 bytes in 1 blocks
==6871== indirectly lost: 0 bytes in 0 blocks
==6871== possibly lost: 0 bytes in 0 blocks
==6871== still reachable: 552 bytes in 1 blocks
==6871== suppressed: 0 bytes in 0 blocks
==6871== Reachable blocks (those to which a pointer was found) are not shown.
==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6871==
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
来自libpcap manpage,
稍作编辑:
pcap_fopen_offline()
return[s] a pointer to a pcap_t
, which is the handle used for reading packets… To close a handle, use pcap_close()
.
free(fd)
只释放一个内存块,因为 free()
对 pcap_t
的内部结构一无所知。为了正确处理分配的资源,您需要使用 pcap_close(fd)
,如文档所示。
我想弄清楚我是否遇到了白痴,或者 libpcap 中是否真的存在内存泄漏。我是 运行 Ubuntu 17.10 和 libpcap 1.8.1-5ubuntu1。这么成熟的库,好像不太可能出现漏洞。
我已经删除了所有内容来制作 MVCE,因此,除了演示泄漏之外,这段代码实际上并没有做太多事情:
#include <stdio.h>
#include <stdlib.h>
#include <pcap.h>
int main(int argc, char **argv)
{
char errbuf[PCAP_ERRBUF_SIZE];
pcap_t *fd = pcap_open_offline(argv[1], errbuf);
if (!fd) {
printf("error: %s\n", errbuf);
}
free(fd); fd = 0;
return 0;
}
valgrind 报告(强调已添加):
==6871==
==6871== HEAP SUMMARY:
==6871== in use at exit: 262,696 bytes in 2 blocks
==6871== total heap usage: 4 allocs, 2 frees, 267,432 bytes allocated
==6871==
==6871== Searching for pointers to 2 not-freed blocks
==6871== Checked 73,072 bytes
==6871==
==6871== 262,144 bytes in 1 blocks are definitely lost in loss record 2 of 2
<b>==6871== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6871== by 0x4E5B89F: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5AE5C: pcap_fopen_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x4E5B05D: pcap_open_offline_with_tstamp_precision (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.8.1)
==6871== by 0x1087A0: main (test.c:9)</b>
==6871==
==6871== LEAK SUMMARY:
==6871== definitely lost: 262,144 bytes in 1 blocks
==6871== indirectly lost: 0 bytes in 0 blocks
==6871== possibly lost: 0 bytes in 0 blocks
==6871== still reachable: 552 bytes in 1 blocks
==6871== suppressed: 0 bytes in 0 blocks
==6871== Reachable blocks (those to which a pointer was found) are not shown.
==6871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6871==
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==6871== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
来自libpcap manpage, 稍作编辑:
pcap_fopen_offline()
return[s] a pointer to apcap_t
, which is the handle used for reading packets… To close a handle, usepcap_close()
.
free(fd)
只释放一个内存块,因为 free()
对 pcap_t
的内部结构一无所知。为了正确处理分配的资源,您需要使用 pcap_close(fd)
,如文档所示。