Re: File descriptor leak involving kqueue

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Robert Swindells <rjs%fdy2.co.uk@localhost> writes:

> I think that close() of a socket can leak the kevent(2) structures
> if there are some still active.

No, I think something else is going on, and it's in the resolver.

In lib/libc/resolv/res_send.c, in the function res_nsend(), res_check()
is called, which in turn calls __res_vinit().  (Not every time, but my
ktrace shows that each leaking of a kqueue fd is preceded by such a
call, and the re-reading of /etc/resolv.conf.)

Now, __res_vinit() unconditionally does this:

	    statp->_u._ext.ext->kq = kqueue1(O_CLOEXEC);

It seems to me that either this needs to check for a kqueue already
existing (e.g. statp->_u._ext.ext->kq > 0), or it's assuming that if
__res_vinit() gets called more than once, everything has been torn down
properly first.  If so, I suspect that at least one of the calls to
res_nclose() in res_nsend() should really be a call to res_ndestroy(),
which does close the kqueue.

Thoughts?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay