[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: File descriptor leak involving kqueue
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.
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
Main Index |
Thread Index |