Re: Possible initialization error in libpcap

[Guy Harris <guy () alum mit edu>]

On Jan 8, 2013, at 7:08 PM, Derek Cole <derek.cole () gmail com> wrote:

> Thanks for the detailed response. You are correct that was my stack overflow post. At the time I posted that I didn't 
> have as clear of an idea of the problem, so, casting a wide net. 
>
> > 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.
>
> I saw that message as well. How did you look up 0x20004269 to know what that corresponded to?

Well, I knew that a 4.2BSD-and-later ioctl code is:

        16 bits of direction and size information;

        16 bits of ioctl code;

and that, by convention, UNIX ioctl codes are 8 bits of ASCII character giving the general class of devices to which 
the ioctl applies and 8 bits of code within that class.

I also knew that, in most of the newer versions of those UN*Xes that have 4.2BSD-style ioctl codes, the direction and 
size information is defined in /usr/include/sys/ioccom.h, so I looked there to find out which of the _IO macros it was.

Then I looked up 0x42 in the "man ascii" table; it was 'b', which wasn't surprising, as that's the class value for BPF 
devices.  I then looked in /usr/include/sys/bpf.h for ioctl 0x69 = 105.

> Can you provide some info about writing a wrapper for an ioctl? I am new to tinkering with this but I was able to get 
> a wrapper for select written today for my freebsd install. I basically copied the pieces from the pselect that was 
> already written for linux and put it in the freebsd source files that came with the port.

So where do the FreeBSD source files hide?  If I look at the FreeBSD ports collection, there's no "files" subdirectory 
of

        http://svnweb.freebsd.org/ports/head/devel/valgrind/

or

        http://svnweb.freebsd.org/ports/head/devel/valgrind-snapshot/

A lot of the wrapper code for Darwin and FreeBSD can probably be similar or even the same (for BPF ioctls, the code can 
probably mostly be shared, modulo handling of stuff such as the Darwin hacks for running {32,64}-bit userland atop 
{64,32}-bit kernels - FreeBSD would probably use similar stuff, but it doesn't have to worry about 64-bit userland atop 
a 32-bit kernel the way Darwin does).
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers