Date: Mon, 7 Jun 2004 23:36:39 +0200 From: Arjan van Leeuwen <avleeuwen@piwebs.com> To: Robert Watson <rwatson@freebsd.org> Cc: "David A. Benfell" <benfell@parts-unknown.org> Subject: Re: file descripter leak in current with Qmail? Message-ID: <200406072336.42196.avleeuwen@piwebs.com> In-Reply-To: <Pine.NEB.3.96L.1040607163727.88690H-200000@fledge.watson.org> References: <Pine.NEB.3.96L.1040607163727.88690H-200000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-02=_q/NxAVpj2Vo26Kq
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Monday 07 June 2004 22:38, Robert Watson wrote:
> On Mon, 7 Jun 2004, Arjan van Leeuwen wrote:
> > On Monday 07 June 2004 21:42, you wrote:
> > > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote:
> > > > > > In terms of debugging it: your first task it to identify if
> > > > > > there's one process that's holding all the fd's, or if it is
> > > > > > distributed over many proceses. After that, you want to track
> > > > > > down what kind of fd is being left open, which may help you track
> > > > > > down why it's left open...
> > > > >
> > > > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT
> > > > > server, which has a _very_ low load (atm, it's only routing the
> > > > > internet traffic for 3 users and serving SMTP for 2 of them). I'm
> > > > > also running qmail. The kernel is from June 6. How do I go about
> > > > > investigating this further?
> > > >
> > > > Replying to myself -
> > > > fstat shows all open files evenly distributed among the running
> > > > processes.
> > >
> > > It could be that this is related to the esd file descriptor leak
> > > problem also being reported. You might also try the attached patch.
> >
> > I get a panic (address not allocated) when using the patch. I can't
> > write down any useful details about it right now, because although the
> > server has only 3 users, they're very disconcerned when I disrupt their
> > internet traffic :).
>
> Doh. Sorry about that. Revised patch attached. I'm able to test the
> leak with the attached C file, and on my test box (now that it doesn't
> panic), the leak appears fixed for non-blocking accepts.
No problem, this patch works like a charm. Thanks!
Arjan
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org Senior Research Scientist, McAfee Research
>
> Index: uipc_syscalls.c
> ===================================================================
> RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v
> retrieving revision 1.187
> diff -u -r1.187 uipc_syscalls.c
> --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187
> +++ uipc_syscalls.c 7 Jun 2004 20:21:30 -0000
> @@ -253,7 +253,7 @@
> {
> struct filedesc *fdp;
> struct file *nfp = NULL;
> - struct sockaddr *sa;
> + struct sockaddr *sa = NULL;
> socklen_t namelen;
> int error;
> struct socket *head, *so;
> @@ -285,7 +285,7 @@
> if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) {
> ACCEPT_UNLOCK();
> error = EWOULDBLOCK;
> - goto done;
> + goto noconnection;
> }
> while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) {
> if (head->so_state & SS_CANTRCVMORE) {
> @@ -296,14 +296,14 @@
> "accept", 0);
> if (error) {
> ACCEPT_UNLOCK();
> - goto done;
> + goto noconnection;
> }
> }
> if (head->so_error) {
> error = head->so_error;
> head->so_error = 0;
> ACCEPT_UNLOCK();
> - goto done;
> + goto noconnection;
> }
> so = TAILQ_FIRST(&head->so_comp);
> KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP"));
>
>
>
> !DSPAM:40c4d2d111291897510869!
--Boundary-02=_q/NxAVpj2Vo26Kq
Content-Type: application/pgp-signature
Content-Description: signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQBAxN/q3Ym57eNCXiERAugaAJ9/7S+U+VknATFRaCRBaaSdcMJWwQCeJXaH
Kef5mH/bJuHrmrc6nrf2rxE=
=/P6F
-----END PGP SIGNATURE-----
--Boundary-02=_q/NxAVpj2Vo26Kq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406072336.42196.avleeuwen>