Date: Wed, 3 Sep 2003 08:50:30 -0700 (PDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: conf/56031: ipfw hangs on every invocation Message-ID: <200309031550.h83FoUej092140@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/56031; it has been noted by GNATS. From: Robert Watson <rwatson@FreeBSD.org> To: "James F. Hranicky" <jfh@cise.ufl.edu> Cc: FreeBSD-gnats-submit@FreeBSD.org, admin@cise.ufl.edu, freebsd-bugs@FreeBSD.org Subject: Re: conf/56031: ipfw hangs on every invocation Date: Wed, 3 Sep 2003 11:45:41 -0400 (EDT) On Wed, 3 Sep 2003, James F. Hranicky wrote: > On Tue, 2 Sep 2003 12:10:28 -0400 (EDT) > Robert Watson <rwatson@FreeBSD.org> wrote: > > > > > On Tue, 2 Sep 2003, James F. Hranicky wrote: > > > > > Let me know if I can provide any more info. > > > > This seems to suggest it's really just the userland application spinning, > > not a hang in the kernel. Could you try using truss to see if, once it > > starts spinning, it's making system calls, or just stuck entirely in > > userspace? > > As far as I can tell it's hanging in the last ioctl() . In, or after? The "Running" state reported by Ctrl-T suggests it is in userspace spinning, perhaps as a result of an unexpected return from the ioctl()... > > Assuming it's purely a userspace problem (perhaps triggered by > > syntactically poor output from the kernel), the next thing to do is > > probably to instrument your ipfw binary with either printfs or debugging > > symbols and see where in its execution it is spinning. > > I can compile it with debugging symbols and trace through the execution, > but it seems like the ioctl() is where it's hanging, again some kind of > odd terminal thing. > > > Could you include a list of your IPFW rules also, please? > > I don't have any set at this time, just the default pass any any. > > I'll trace through it with gdb if you think it will help. I'd step up to the ioctl in question, and then see if it really hangs in the ioctl(), or if it gets past and starts spinning. If it's the ioctl(), it would be very helpful to know which file descriptor it's on, and what the arguments are. If it's not the ioctl() call, we need to figure out which loop isn't taking something important into account. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309031550.h83FoUej092140>