On 06/30/2011 07:18 PM, Antoine Preteux wrote:
> Hello,
> 
> One of our customer has an issue which could be linked to the problem explain 
> in the thread Av Timeout.
> 
> Version 0.97 self compiled on Linux/Etch.

This is a different problem, the problem in the Av Timeout thread is specific 
to code introduced in 0.97.1.

> Config.log here : http://dl.free.fr/lPN1ukvMf
> 
> We mostly use clamd as a gateway AV (squid+icap)
> 
> We caught a core dump and you can get it here with the binary :

This is a hang/freeze, and not a crash right?
clamdscan not respdoning to -V and PING as in the AV timeout thread?

> 
> http://dl.free.fr/bP3ZEIYU6

I'd need these files too:
/usr/lib/libclamav.so.6
/lib/libpthread.so.0
/lib/libc.so.6
/usr/lib/libstdc++.so.6
/usr/lib/libz.so.1
/lib/libbz2.so.1.0.0
/lib/libm.so.6
/lib/libdl.so.2
/lib/libgcc_s.so.1
/lib/ld-linux.so.2
/usr/lib/libclamunrar_iface.so.6.1.9
/usr/lib/libclamunrar.so.6
/usr/lib/gconv/UTF-16.so

And if you can this in gdb:
(gdb) info thread
(gdb) thread apply all bt

The output from the backtrace is probably too large for this ML, so it might be 
better
if you open a bug at bugs.clamav.net and attach that info there.

> 
> Unfortunatelly we couldn't save scanned files.
> We couldn't reproduce the problem.
> All processing threads seems to be blocked in fmap.c + ole2 file
> "
> Thread 5 (process 11669):
> #0  0xb73efb64 in __pthread_sigsuspend () from /lib/libpthread.so.0
> #1  0xb73ee728 in __pthread_wait_for_restart_signal () from 
> /lib/libpthread.so.0
> #2  0xb73f0fe6 in __pthread_alt_lock () from /lib/libpthread.so.0
> #3  0xb73ee1dc in pthread_mutex_lock () from /lib/libpthread.so.0
> #4  0xb74fb3b3 in fmap_readpage (m=0xaeebe000, first_page=3074383860, 
> count=8, lock_count=0) at fmap.c:215
> #5  0xb74fb7da in fmap_need (m=0xaeebe000, at=918016, len=<value optimized 
> out>, lock=0) at fmap.c:346
> #6  0xb749a22d in ole2_read_block (hdr=<value optimized out>, 
> buff=0xb0dad6ec, size=512, blockno=1792) at ole2_extract.c:292
> [...]

This only means there is heavy contention on this mutex, and AFAICT the mutex 
is released eventually on all code paths.
0.97.1 reduces the contention on this mutex a bit.

Are all the threads in fmap_readpage?

Best regards,
--Edwin
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

Reply via email to