Date: Tue, 24 May 2005 17:51:53 -0400 From: Ed Maste <emaste@phaedrus.sandvine.ca> To: freebsd-stable@freebsd.org Cc: jmg@freebsd.org Subject: Re: libc_r kqueue fd leak Message-ID: <20050524215153.GA35718@sandvine.com> In-Reply-To: <20050524173648.GA29183@sandvine.com> References: <20050524165907.GA20674@sandvine.com> <20050524173648.GA29183@sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 24, 2005 at 01:36:48PM -0400, Ed Maste wrote: > On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote: > > > 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. > > I've attached a patch which stops libc_r close() from bailing if fstat() > returns an error. This fixes the kqueue leak. This logic would also have > to make its way into the compat library via 4.x to fully resolve the issue. After a little more research it seems the kernel fix is already documented in threads/75795. Version 1.77 of kern_event.c changed kqueue_stat to just return ENXIO. We discovered the problem because each call in our app to getipnodebyname (and in turn the resolver) leaked one kqueue, which eventually used up all kernel memory and then caused a panic. I noticed that jmg originally did the kqueue locking work which removed kqueue_stat, hence the CC:. Thanks, Ed -- Ed Maste, Sandvine Incorporated
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050524215153.GA35718>