Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2005 12:59:07 -0400
From:      Ed Maste <emaste@phaedrus.sandvine.ca>
To:        freebsd-stable@freebsd.org
Subject:   libc_r kqueue fd leak
Message-ID:  <20050524165907.GA20674@sandvine.com>

next in thread | raw e-mail | index | archive | help
We discovered a kqueue leak when running one of our 4.x applications on
FreeBSD 5.3 using the compat libc_r.  It turns out it's caused by libc_r's
close() failing.

The libc_r close (in uthread_close.c) calls fstat() on the file
descriptor.  On 4.x this succeeds, while on 5.x the fstat() on the kqueue()
fd returns -1 with errno=0.  The close() in libc_r then returns this error
without doing the actual close syscall.

I built the test application shown below on a 4.7 and 5.3 machine
and fstat returns 0 on 4.7, -1 on 5.3.  If the test app is linked against
libc_r then the close() fails too.

fstat(2) indicates that fstat() returns a mostly-zeroed buffer for a socket
fd, but gives no indication of what should happen for a kqueue fd.  What is
the expected behaviour here?  The issue could be fixed by either having the
kernel not fail the fstat, or making libc_r ignore the failure and continue
on with the close.

== kqueue.c ==

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/event.h>
#include <errno.h>

int main()
{
    struct stat sb;
    int kq=kqueue();
    printf("fstat returns %d (%d)\n", fstat(kq, &sb), errno);
    printf("close returns %d (%d)\n", close(kq), errno);
}

--
Ed Maste, Sandvine Incorporated



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050524165907.GA20674>