Re: file descriptor leak in 5.2-RC

On Fri, 19 Dec 2003, Kris Kennaway wrote:

> On Fri, Dec 19, 2003 at 11:30:40AM +0100, Michal Mertl wrote:
> > On Thu, 18 Dec 2003, Jonathan Lennox wrote:
> > > Michal Mertl writes:
> > > > For several weeks now I see my -current (now RELENG_5_2 to help test the
> > > > release) machine seems to be leaking file descriptors. After some time all
> > > > files (up to kern.maxfiles) are consumed.
> > >
> > > Do you have any statically-linked programs that use pthreads?  There's a FD
> > > leak in gethostbyname(3) in multithreaded programs (actually, in the uthread
> > > wrapper for kevent(2), but gethostbyname(3) is the most common reason you'd
> > > see it) which was fixed in -CURRENT for programs linked with libc_r.so, but
> > > not for those linked with libc_r.a.
> > 
> > I'm afraid this is different. When your program terminates the descriptors
> > are freed. You found a bug but it's not that serious as what I'm seeing -
> > even when I go to single-user I see large openfiles.
> 
> Someone else already asked you to check fstat to see what the open files
> are, and suggested it's probably the dynamic linker (i.e. expected
> behaviour).  What is the case? 

However, he pointed out that they were still all allocated when he
returned to single-user mode.  That means that all the processes, with the
exception of init(8), should have been killed off, and a new shell
started.  So unless his shell is linking against thousands of libraries,
that is likely not the case.  fstat(8) works by walking the file
descriptor arrays of all processes, so if we actually have a leak,
fstat(8) should show a small number of files, but the sysctl
kern.openfiles should reveal a large number of files open. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research