stable libmilter leaks kqueue descriptors?

[Andre Albsmeier]

On Wed, 30-Jul-2003 at 15:46:24 +0000, othermark wrote:
> In article <slrnbidfm6.11jf.atkin901 at adkinson245.f5net.com>, othermark wrote:
> > 2. have some ideas on how to track down this leakage?  I've looked
> >    at the dccm source and it seems to be using milter correctly
> >    (as it was working fine with an older version of sendmail), but
> >    maybe other excellent users have tracked down kqueue leakage
> >    before.
> 
> I found this pr, which seems to be a likely candidate.  
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/55007
> 
> dccm is threaded, but libmilter does not call kqueue directly, but
> based on other searches, I'm suspecting that various calls are
> implemented using kqueue, kevent (select(), poll(), etc..).  I see
> some evidence of this in the sources, but I'm not familiar enough
> with the kernel code to say absolutely that these code paths are
> executed.

I have a self-written milter app. Today I upgraded to the recent
-STABLE and now it eats KQUEUE filedscriptors like crazy. I tried
to MFC the fix in lib/libc_r/uthread/uthread_kqueue.c but I always
get complaints about multiple definition of `_kqueue':

building shared library libc_r.so.4
kqueue.So: In function `_kqueue':
kqueue.So(.text+0x14): multiple definition of `_kqueue'
uthread_kqueue.So(.text+0x0): first defined here
*** Error code 1

Seems it conflicts with /usr/obj/lib/libc_r/kqueue.S
which is generated everytime from scratch during the build.

I assume that I have to add kqueue.o to HIDDEN_SYSCALLS
but I am not sure if this is correct and what it will break :-)

	-Andre