Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <003b01c50640$5a2c1840$173ca8c0@AlohaSunset.com> From: "Mark Pizzolato" To: "Reini Urban" , References: <41FBD281 DOT 2020108 AT x-ray DOT at> Subject: Re: pthreads leaks handles and threads when threads use sockets Date: Sat, 29 Jan 2005 12:23:08 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0038_01C505FD.4AC1D950" X-OriginalArrivalTime: 29 Jan 2005 20:23:13.0584 (UTC) FILETIME=[5BAFAB00:01C50640] X-IsSubscribed: yes Note-from-DJ: This may be spam ------=_NextPart_000_0038_01C505FD.4AC1D950 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Reini, > Reini Urban wrote: > Mark Pizzolato schrieb: > > I've been using clamav's clamd under cygwin and noticed that over time > > the handle count as viewed with TaskManager seems to grow to arbitrary > > values. I used clamd's option IdleTimeout set to 600 seconds which > > dramatically reduced the growth rate of the Handle Count. Of course > > clamd has many things going on that could contribute to handle leakags, > > so I tried to write a simple program to demonstrate the problem. > > Thanks a lot! Maybe we should restart the two daemons daily or weekly? > > I will change the default IdleTimeout to 600 secs with the upcoming > clamav-0.81 release. Which fixes the freshclam proxy problem and some > OLE issues. Merely setting IdleTimeout to 600 is currently insufficient due to a bug which only uses the IdleTimeout parameter for the Initial value used. After the AV Database is reloaded, the idle timeout is hardset to 30 seconds. The attached patch (to 0.80 or 0.81) fixes this issue. This patch has been submitted on the clamav-devel list. The right choice for the IdleTimeout is a value which is larger than the largest gap between messages that arrive on your system. This is somewhat complicated by multiple connections arriving concurrently which is handled by MaxThreads. MaxThreads has a default value of 10. This would be fine for most systems, however libclamav uses tmpfile() internally which is NOT threadsafe (using newlib's tmpfile()) for any system which returns the same value for getpid() for each thread in a process (i.e. it works fine on Linux since getpid() on Linux returns a unique value for all threads on the system). I've submitted changes which address this to the clamav folks(avoiding tempfile()), but they have not been accepted as yet. To avoid this issue (and avoid clamd producing "ERROR: ScanStream: Can't create temporary file." messages), setting MaxThreads to 1 should work, but will probably affect the behavior of client software that talks to it (possibly causing deadlocks). Do you have any insight to help address the underlying socket issues in threaded programs would clearly help with clamd and every other multi threaded program which may not even know it has these issues. - Mark Pizzolato ------=_NextPart_000_0038_01C505FD.4AC1D950 Content-Type: application/octet-stream; name="idletimeout.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="idletimeout.patch" --- server-th.c.orig 2005-01-28 15:57:49.848384200 -0800=0A= +++ server-th.c 2005-01-28 15:58:37.828811900 -0800=0A= @@ -557,7 +557,7 @@=0A= */=0A= thrmgr_destroy(thr_pool);=0A= root =3D reload_db(root, copt, FALSE);=0A= - if((thr_pool=3Dthrmgr_new(max_threads, 30, scanner_thread)) =3D=3D NU= LL) {=0A= + if((thr_pool=3Dthrmgr_new(max_threads, idletimeout, scanner_thread)) = =3D=3D NULL) {=0A= logg("!thrmgr_new failed\n");=0A= pthread_mutex_unlock(&reload_mutex);=0A= exit(-1);=0A= ------=_NextPart_000_0038_01C505FD.4AC1D950 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ------=_NextPart_000_0038_01C505FD.4AC1D950--