Clamav-90_2 Lockup with freebsd 6.2

Daniel Eischen 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 
> 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


More information about the freebsd-stable mailing list