Home/ Questions/Q 9107409
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T02:33:53+00:00

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

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0