On Jan 8, 2013, at 1:58 PM, Derek Cole <derek.c...@gmail.com> wrote:
> I am not sure this is the right mailing list for this or not,
It is. "tcpdump-workers" is actually a combination of:
"tcpdump-users" - users of tcpdump;
"tcpdump-workers" - developers of tcpdump;
"libpcap-users" - "users" of libpcap, i.e. developers of programs using
libpcap (including tcpdump) asking questions about using libpcap;
"libpcap-workers" - developers of libpcap.
> I am trying to debug some software that is using libpcap, with valgrind.
This is presumably on FreeBSD, as per your StackOverflow question at
http://stackoverflow.com/questions/14218085/valgrind-errors-with-pcap-initialization
Presumably this is a port of valgrind to FreeBSD, as
> I am not able to get my software to launch, because valgrind is returning the
> dump at the bottom of the email.
Valgrind is complaining about several uninitialized variables, *and* about
"unhandled ioctl 0x20004269 with no size/direction hints". 0x20004269 is
_IO('B', 105), which is BIOCPROMISC. BIOCPROMISC takes no arguments, so there
is no size or direction. However, an ioctl that takes arguments that aren't a
simple fixed-size blob would also have no size/direction hints, so valgrind
doesn't just assume there's nothing to check. If that warning is causing a
problem, you'll have to write a wrapper for that ioctl to let valgrind know
that there are no arguments and therefore that no references to memory are made
by it.
In your StackOverflow question, valgrind also complains about
> 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.
Yes, that's pselect(). I'm not sure why that's being called, unless select()
is now a wrapper around it, but you may have to write a wrapper for that as
well.
> As far as I can tell, I think all of the parameters I am passing are in fact
> initialized, so is there a problem in
> pcap itself?
Possibly, *IF* there's an issue with ioctl arguments being used.
Unfortunately, there aren't any line numbers, but I'm guessing that "???" is
pcap_activate_bpf(), which is the module that implements pcap_activate() on
systems with BPF (*BSD, OS X, AIX).
Looking at the code, there is one issue with an ioctl used for the
memory-mapped capture mechanism in FreeBSD - the argument to BIOCGETZMAX is a
size_t, but libpcap is passing a pointer to a u_int. That shouldn't cause an
uninitialized-byte variable, as it's *writing* the variable, not *reading* it,
but it *does* need to be fixed so that random crap isn't overwritten on the
stack on 64-bit platforms.
BIOCSETIF is being passed a pointer to a not-completely-initialized struct
ifreq; however, the only part that's actually looked at in the structure, the
interface name, *is* initialized.
I'm not sure what the
> ==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)
complaint is about. It *might* be due to valgrind not understanding
BIOCGDLTLIST, which is not a simple ioctl (you pass into it a structure
containing a length and a pointer, and the kernel fills in the array pointed to
by the pointer with a number of elements limited by the length).
So I suspect most if not all of your problems are due to valgrind not
understanding BPF ioctls, not due to actual problems in your code or in libpcap.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
