Valgrind errors with pcap initialization

Question

I am trying to use Valgrind on FreeBSD and running into some issues. Here is the output

==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

That last warning, repeats over and over, but I dont think it is necessarily a problem, right? More concerning is the other problem I think.

It looks like my program is still running in the background, but I obviously dont get a good report from valgrind. One of the offending lines that it is mentioning is pcaputil:77

which is the following:

pd=pcap_open_live(__intf, snaplen, 1, 512, ebuf)

where _intf is a char *, snaplen is an int, and ebuf is a char ebuf[SIZE] = {0}; array

Have you [read this](http://valgrind.org/docs/manual/dist.readme-missing.html)? — netcoder, Jan 08 '13 at 15:23
Yes, I had actually read that page previously. The instructions are a little vague, but I think maybe it was complaining about SYS_pselect, but thats only because I found a definition of that that correlates to 522, which is what it was complaining about. I havent been able to fin dnay examples of people wriitng their own example wrappers completely though — Derek, Jan 08 '13 at 15:58
Well, are you sure that `__intf` and `snaplen` are initialized? — Philip, Jan 08 '13 at 20:27
Yes, I am sure. I even tried just putting in constant values. Is it possible that pcap itself is the actual problem here? — Derek, Jan 08 '13 at 21:51

score 1 · Accepted Answer · answered Jan 10 '13 at 04:27

Actually, that's just Valgrind-for-FreeBSD not really understanding some ioctls. The same problem exists on OS X (and would probably exist on all the other *BSDs); see Valgrind bug 312989 (they use KDE's bug database; they haven't really had over 300,000 bugs :-)).

The fix for FreeBSD would be similar, although, for some reason, they decided to go with the Linux convention of "copy all the stuff from include files into the Valgrind source" rather than the Darwin convention of "just include the system header files"; this means there'd be a bit more work needed for the header files. I'll ask the FreeBSD Valgrind maintainers whether the Darwin approach would be better.

score 0 · Answer 2 · edited Jun 01 '20 at 20:58

Well, there is a bug with Valgrind. There is a system call in FreeBSD it doesn't handle. Probably something that pcap calls. There's a chance that this is propagating and causing Valgrind to say pcap is jumping on uninitialized data. There's even a chance that your program is working just fine and it's just Valgrind that has issues. The best course would be to add your own ioctl wrapper, patch valgrind, and see if it still freaks out. Or you could use an alternative to pcap which doesn't make use of whatever system call it's using.

Sorry if that's not a simple solution.

Valgrind errors with pcap initialization

2 Answers2