Re: Possible initialization error in libpcap

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

Well, after tracking down some of the structures being used in the ioctl
arguments, and memset() them to zero, I think all of the errors went away
without the need to write any additional wrappers other than the pselect()
wrapper. Most of those calls were int he bpf-pcap.c file. I am not sure
whether that is a worthwhile check-in to make for pcap or not.

-Derek

On Wed, Jan 9, 2013 at 10:21 AM, Derek Cole <derek.cole () gmail com> wrote:

> 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