Re: Possible initialization error in libpcap

[Derek Cole <derek.cole () gmail com>]

Thanks,

That might be enough information for me to get a start on tackling some of
this.

Just for reference, this is the version of valgrind for FreeBSD i've been
working off of

http://wiki.freebsd.org/Valgrind


On Tue, Jan 8, 2013 at 11:32 PM, Guy Harris <guy () alum mit edu> wrote:

> 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