From owner-freebsd-stable@FreeBSD.ORG Sun Mar 4 23:43:46 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E1B516A402 for ; Sun, 4 Mar 2007 23:43:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C4AFA13C478 for ; Sun, 4 Mar 2007 23:43:45 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l24NhhJj004275; Sun, 4 Mar 2007 18:43:44 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Sun, 04 Mar 2007 18:43:44 -0500 (EST) Date: Sun, 4 Mar 2007 18:43:43 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Martin Blapp In-Reply-To: <20070304214255.O18301@godot.imp.ch> Message-ID: References: <003701c75a03$fb478ac0$d801a8c0@dimuthu> <200702270305.l1R35MX2067221@lava.sentex.ca> <20070227035603.GA49430@tmn.ru> <20070227183553.B18301@godot.imp.ch> <20070304214255.O18301@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ClamAV Development , freebsd-stable@freebsd.org Subject: Re: Clamav-90_2 Lockup with freebsd 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2007 23:43:46 -0000 On Sun, 4 Mar 2007, Martin Blapp wrote: > > Hi all, > > After adding some debug stuff to clamd running with freebsd > libpthread.so I found that: > > looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l' > is always staying at 6 threads, but the number of threadpool->thr_alive is > going higher and higher. So threadpool->thr_alive isn't decreased and > is completly incorrect. > > In my tests the number of threads with libpthread.so is never going higher > than 6 threads. That explains, why a higher load is going to delay all scan > operations more and more. > > With libthr.so the value of threadpool->thr_alive is equal with the output of > the ps. It can go very high, but always goes back if no more > work is there to do. > > After the maxthreads limit is reached, clamd becomes completly unresponsive > with libpthreads.so. > > SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block > on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter > threadpool->thr_alive is wrong and may cause this problem. > > Maybe someone with more threads knowledge can help here. I'll now add some > debug > stuff to see where threadpool->thr_alive is going to be increased and where > it > is decreased. The strange thing is that this works fine with libthr.so. Make sure clamd is checking the return value of pthread_create() for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process scope or system scope threads (libpthread only) for clamd. -- DE