我试图在FreeBSD上使用Valgrind并遇到一些问题。这是输出
==4764== Memcheck, a memory error detector
==4764== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4764== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==4764== Command: driver -i
==4764==
==4764==
==4764== HEAP SUMMARY:
==4764== in use at exit: 33,852 bytes in 4 blocks
==4764== total heap usage: 12 allocs, 8 frees, 171,894 bytes allocated
==4764==
==4764== LEAK SUMMARY:
==4764== definitely lost: 0 bytes in 0 blocks
==4764== indirectly lost: 0 bytes in 0 blocks
==4764== possibly lost: 0 bytes in 0 blocks
==4764== still reachable: 33,852 bytes in 4 blocks
==4764== suppressed: 0 bytes in 0 blocks
==4764== Rerun with --leak-check=full to see details of leaked memory
==4764==
==4764== For counts of detected and suppressed errors, rerun with: -v
==4764== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==4765== Syscall param ioctl(generic) points to uninitialised byte(s)
==4765== at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765== by 0x1A40469: ??? (in /lib/libpcap.so.8)
==4765== by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765== by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765== by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765== by 0x120FE6A: driver_init (recfm.c:387)
==4765== by 0x402633: main (driver.c:224)
==4765== Address 0x7ff000270 is on thread 1's stack
==4765== Uninitialised value was created by a stack allocation
==4765== at 0x1A3FED0: ??? (in /lib/libpcap.so.8)
==4765==
==4765== Conditional jump or move depends on uninitialised value(s)
==4765== at 0x1A408DD: ??? (in /lib/libpcap.so.8)
==4765== by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765== by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765== by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765== by 0x120FE6A: driver_init (recfm.c:387)
==4765== by 0x402633: main (driver.c:224)
==4765== Uninitialised value was created by a heap allocation
==4765== at 0x1008DAB: malloc (vg_replace_malloc.c:274)
==4765== by 0x1A4013E: ??? (in /lib/libpcap.so.8)
==4765== by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765== by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765== by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765== by 0x120FE6A: driver_init (recfm.c:387)
==4765== by 0x402633: main (driver.c:224)
==4765==
==4765== Warning: noted but unhandled ioctl 0x20004269 with no size/direction hints This could cause spurious value errors to appear. See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.Syscall param ioctl(generic) points to uninitialised byte(s)
==4765== at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765== by 0x1A40291: ??? (in /lib/libpcap.so.8)
==4765== by 0x1A3ED18: pcap_activate (in /lib/libpcap.so.8)
==4765== by 0x1A3F43A: pcap_open_live (in /lib/libpcap.so.8)
==4765== by 0x1822DB7: pcap_init (pcaputil.c:77)
==4765== by 0x120FE6A: driver_init (recfm.c:387)
==4765== by 0x402633: main (driver.c:224)
==4765== Address 0x7fefffd14 is on thread 1's stack
==4765== Uninitialised value was created by a stack allocation
==4765== at 0x1A3FEF8: ??? (in /lib/libpcap.so.8)
==4765==
==4765== Syscall param ioctl(generic) points to uninitialised byte(s)
==4765== at 0x3196CBC: __sys_ioctl (in /lib/libc.so.7)
==4765== by 0x1A40C98: ??? (in /lib/libpcap.so.8)
==4765== by 0x1823277: pcap_init (pcaputil.c:98)
==4765== by 0x120FE6A: driver_init (recfm.c:387)
==4765== by 0x402633: main (driver.c:224)
==4765== Address 0x7ff000454 is on thread 1's stack
==4765== Uninitialised value was created by a stack allocation
==4765== at 0x1822C10: pcap_init (pcaputil.c:61)
==4765==
--4765-- WARNING: unhandled syscall: 522
--4765-- You may be able to write your own handler.
--4765-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4765-- Nevertheless we consider this a bug. Please report
--4765-- it at http://valgrind.org/support/bug_reports.html.
...repeated a bunch of times
最后一次警告，一遍又一遍地重复，但我认为这不一定是个问题，对吧？更令人担忧的是我认为的另一个问题。
看起来我的程序仍然在后台运行，但我显然没有得到valgrind的好报告。它提到的一个令人不快的行是pcaputil：77
以下内容：
pd=pcap_open_live(__intf, snaplen, 1, 512, ebuf)
其中_intf是char *，snaplen是int，ebuf是char ebuf[SIZE] = {0};数组
答案 0 :(得分：1)
实际上，这只是Valgrind-for-FreeBSD并不是真正了解一些ioctls。 OS X上存在同样的问题（并且可能存在于所有其他* BSD上）;请参阅Valgrind bug 312989（他们使用KDE的错误数据库;他们实际上没有超过300,000个错误： - ））。
FreeBSD的修复程序类似，但由于某些原因，他们决定采用“将所有内容从包含文件复制到Valgrind源代码”的Linux惯例，而不是“只包括系统”的达尔文惯例头文件“;这意味着头文件需要更多的工作。我会问FreeBSD Valgrind维护者Darwin方法是否会更好。
答案 1 :(得分：0)
嗯，Valgrind有一个错误。在freeBSD中有一个系统调用它无法处理。可能就是pcap所说的。这可能是传播并导致Valgrind说pcap正在跳过未初始化的数据。甚至有可能你的程序工作得很好，只是Valgrind有问题。最好的方法是添加你自己的ioctl包装器，修补valgrind，看看它是否仍然吓坏了。或者您可以使用pcap的替代方法，它不会使用它正在使用的任何系统调用。
很抱歉，如果这不是一个简单的解决方案。