If you find a bug in ClamAV, please check it against the latest git code .

If it’s not fixed yet, visit our bug tracker .

Please do not report any bug affecting software derived from ClamAV and distributed by a third party (i.e. ports we do not maintain directly) because we have no control over them.
Contact their developers instead.

Here are the information you must include in your bug report (in order of importance):

• E-mail address: 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:

  clamconf -n

• 3rd party signatures: whether you are using any unofficial signature databases, that is anything other than main.cvd/cld and daily.cvd/cld
• System details: full specs of your system: i.e. output from:

  uname -mrsp

• Library versions: 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! E.g.:

  zip -P virus -e file.zip file.ext

  The content of the file will be kept confidential. Alternatively 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 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
  Segmentation fault

  The first thing to do is having the kernel write a core dump. For bourne-like shells (e.g. bash):

  $ ulimit -c unlimited

  For C-like shells (e.g. tcsh):

  > limit coredumpsize unlimited

  Now you should see the core dumped message:

  $ clamscan --some-options some_file
  Segmentation fault (core dumped)

  Looking at your current working directory should reveal a file named core.

  The next step is to load the core file into gdb:

  $ gdb -core=core --args clamscan --some-options some_file
  (gdb)

  You should now see the gdb prompt. Just use the bt command at the prompt to make gdb print a full backtrace.
  Copy and paste it into the bug report. You can use the q command to leave gdb.

• Backtrace of clamd:

  Use 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:

  (gdb)

  If you want clamd to continue running, until a segmentation fault occurs for example, issue the continue gdb command, and wait for an error, at which point gdb will return to its prompt. bt will give a backtrace for the current thread. The command info threads will tell you how many threads there are. The command thread n 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 do:

  info threads to get the number of threads and their id numbers

  For each thread do:

  thread id_number
  bt

  Exit from gdb with the quit command. Reply y to the question about the program still running.

• Strace: optionally, if you think it can help, the output from strace (not covered here).

  Warning: unless differently stated, we do not maintain any binary packages & ports directly. Those packages are contributed by third parties.

  We take no responsibility for them!

  Please note that we do NOT accept reports for bugs that only affect a package we do not maintain!
  When in doubt always compile ClamAV from sources.