If you find a bug in ClamAV, please check it against the latest git code. Read the instructions below, then visit our bug tracker to submit your bug report. Please do not submit bugs for third party software.
Please be sure to include all of the following information so that we can effectively address your bug:
a working email address so the developers can get in touch with you to obtain additional info and notify you when the problem is fixed.
ClamAV version and settings:
the output from:
3rd party signatures:
whether you are using any unofficial signature databases, that is anything other than main.cvd/cld and daily.cvd/cld
full specs of your system: i.e. output from:
your libc and possibly zlib versions
How to reproduce the problem:
if the issue is reproducible only when scanning a specific file, attach it to the message. Don’t forget to encrypt it or you may cause damage to the mail servers between you and us!
zip -P virus -e file.zip file.ext.
The content of the file will be kept confidential.
If the file is too big to mail it, you can upload it to a password protected website and send us the URL and the credentials to access it.
Backtrace of clamscan: If possible, please send us the backtrace obtained from gdb, the GNU Project Debugger. Here are step by step instructions which will guide you through the process. Assuming you get something like:
$ clamscan --some-options some_file
$ ulimit -c unlimited
For C-like shells (e.g. tcsh):
limit coredumpsize unlimited
Looking at your current working directory should reveal a file named core.
$ gdb -core=core --args clamscan --some-options some_file
You should now see the gdb prompt.
btcommand at the prompt to make gdb print a full backtrace. Copy and paste it into the bug report. You can use the
qcommand to leave gdb.
ps to get the PID of clamd (first number from the left):
$ ps -aux (or ps -elf on SysV)
clamav 24897 0.0 1.9 38032 10068 ? S Jan13 0:00 clamd
Attach gdb to the running process:
$ gdb /usr/sbin/clamd 24897
Replace 24897 with the pid of clamd and adjust the path of clamd.
You should now get the gdb prompt, as:
If you want clamd to continue running (i.e. until a segmentation fault occurs), issue the
continue gdb command, and wait for an error, at which point gdb will return to its prompt.
will give a backtrace for the current thread.
will tell you how many threads there are.
will change to the specified thread, after which you can use the bt command again to get it’s backtrace.
So, you basically want to use
info threads to get the number of threads and their id numbers; and for each thread do
thread id_number; then
bt. Exit from gdb with the
quit command. Reply
y to the question about the program still running.
Optionally, if you think it can help, the output from
strace can be included in the report (not covered here).