Clamav-90_2 Lockup with freebsd 6.2
deischen at freebsd.org
Sun Mar 4 23:43:46 UTC 2007
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
> stuff to see where threadpool->thr_alive is going to be increased and where
> 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.
More information about the freebsd-stable