[Pkg-clamav-devel] Bug#749027: Bug#749027: The ClamAV daemon stops working.

[Andreas Cadhalpun]

Control: forwarded -1 https://bugzilla.clamav.net/show_bug.cgi?id=11028

Hi Jim,

On 04.06.2014 10:40, Jim Barber wrote:
> Okay, I have a hang, and I have the gdb output that you want.

Thanks for the backtrace.

> First the PID and Threads:
>
> # ps -eL | grep -P 'LWP|clamd'
>    PID   LWP TTY          TIME CMD
> 26124 26124 ?        00:00:11 clamd
> 26124 26126 ?        00:00:00 clamd

Two threads, that's normal.

> Then connecting to the first thread via gdb:
>
> # gdb /usr/sbin/clamd 26124
[...]
> (gdb) bt full
> #0  __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

So indeed this looks like a deadlock. But that's strange, as the other 
thread seems to be idle...

> No locals.
> #1  0x00007ff480483467 in _L_lock_913 () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> No symbol table info available.
> #2  0x00007ff480483290 in __GI___pthread_mutex_lock (mutex=0x6256a0
> <logg_mutex>) at ../nptl/pthread_mutex_lock.c:79
>          __PRETTY_FUNCTION__ = "__pthread_mutex_lock"
>          type = 4294966784
> #3  0x0000000000405f5f in logg (str=str at entry=0x41f8c9 "Reading
> databases from %s\n") at ../shared/output.c:350

../shared/output.c:350 is:
     pthread_mutex_lock(&logg_mutex);

That's surprising: I had thought the deadlock would happen with the 
reload_mutex, but it actually happens with the logg_mutex.
It tries to log "Reading databases from /var/lib/clamav" and for this 
wants to lock the logg_mutex, but the mutex is apparently already 
locked, so clamd hangs.

I can't see how this could happen, as the logg_mutex is always unlocked, 
before logg() returns, and the other thread is not in the process of 
logging something.

> Then I attach gdb to the other thread:
>
> # gdb /usr/sbin/clamd 26126
[...]
> (gdb) bt full
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

This thread is just waiting.

> #1  0x000000000040c421 in acceptloop_th (arg=0x7ffff5a3e540) at
> server-th.c:378
> #2  0x00007ff480481062 in start_thread (arg=0x7ff4651b9700) at
> pthread_create.c:312
> #3  0x00007ff4801b4c1d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
[...]
> If there is anything else you need me to do (such as install other
> debug packages from some of the dependent libraries), let me know.

I have forwarded this to upstream now. Let's see, what they say.

Best regards,
Andreas