Hello,
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? 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.
You were correct that the pcap_activate_bpf() is the location of the
problem. I compiled my own copy of pcap so I could debug and step into the
source. I had seen that ifreq structure, and I thought I may need to memset
that to zero even though the only thing that was being accessed was the
interface name.
As I said before, I tinkered around with getting the 522 warning to go away
by copying the pselect() from the linux source into the FreeBSD sources. I
basically read the README and started messing around without really knowing
what I was doing. is there a safe way to implement a quick "do nothing" for
these ioctl's that are not already there? Again, if you have any examples
or source code that I should be looking at to get an idea, I'd appreciate
it. Tomorrow I will post the current output from valgrind after having
implemented my pselect wrapper. i dont think most things changed, but i do
think it gave me source lines on my compiled pcap lib.
Thanks
On Tue, Jan 8, 2013 at 6:08 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
> 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
