Date: Sun, 4 Mar 2007 22:16:42 +0100 (CET) From: Martin Blapp <mb@imp.ch> To: ClamAV Development <clamav-devel@lists.clamav.net> Cc: deischen@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Clamav-90_2 Lockup with freebsd 6.2 Message-ID: <20070304214255.O18301@godot.imp.ch> In-Reply-To: <20070227183553.B18301@godot.imp.ch> References: <003701c75a03$fb478ac0$d801a8c0@dimuthu> <200702270305.l1R35MX2067221@lava.sentex.ca> <20070227035603.GA49430@tmn.ru> <20070227183553.B18301@godot.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070304214255.O18301>