Re: [Bug 691414] [NEW] clamav taking extremely long time to load database

2010-12-16 Thread Scott Kitterman
What architecture is this? I don't see this on i386.  Also what's the
exact CPU?

I don't think the security patches would have affected this.

Can you replicate this with the newer clamav in backports?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to clamav in ubuntu.
https://bugs.launchpad.net/bugs/691414

Title:
  clamav taking extremely long time to load database

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 691414] [NEW] clamav taking extremely long time to load database

2010-12-16 Thread Kees Cook
Public bug reported:

Binary package hint: clamav

# apt-cache policy clamav-daemon
clamav-daemon:
  Installed: 0.96.3+dfsg-2ubuntu1.0.10.04.2
  Candidate: 0.96.3+dfsg-2ubuntu1.0.10.04.2

Since the security update of clamav, the daemon takes multiple minutes
to load its virus database, and is causing random timeouts for users of
the unix socket (in my case, mimedefang), triggering repeated 400-series
email temp-fails each time freshclam issues a reload request.

strace just shows it slowly allocating memory and not doing much else.

Logs don't seem to help:
Thu Dec 16 20:58:34 2010 -> +++ Started at Thu Dec 16 20:58:34 2010
Thu Dec 16 20:58:34 2010 -> clamd daemon 0.96.3 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
Thu Dec 16 20:58:34 2010 -> Log file size limit disabled.
Thu Dec 16 20:58:34 2010 -> Reading databases from /var/lib/clamav/
Thu Dec 16 20:58:34 2010 -> Not loading PUA signatures.
Thu Dec 16 20:58:38 2010 -> Loaded 856324 signatures.

But minutes later, it's still spinning at 100% CPU and non-responsive on
its socket.

Here's the backtrace while its stuck:

(gdb) bt
#0  __find<__gnu_cxx::__normal_iterator > >, 
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=) at /usr/include/c++/4.4/bits/stl_algo.h:186
#1  find<__gnu_cxx::__normal_iterator > >, 
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=) at /usr/include/c++/4.4/bits/stl_algo.h:4224
#2  llvm::LoopBase::contains (this=0x1a9f300, 
L=0x1466740, ExitingBlock=)
at ./llvm/include/llvm/Analysis/LoopInfo.h:108
#3  llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit (this=0x1a9f300, 
L=0x1466740, ExitingBlock=)
at llvm/lib/Analysis/ScalarEvolution.cpp:3612
#4  0x7f6591bad79f in llvm::ScalarEvolution::ComputeBackedgeTakenCount 
(this=0x1a9f300, L=0x1466740)
at llvm/lib/Analysis/ScalarEvolution.cpp:3542
#5  0x7f6591badaa5 in llvm::ScalarEvolution::getBackedgeTakenInfo 
(this=0x1a9f300, L=0x1466740) at llvm/lib/Analysis/ScalarEvolution.cpp:3415
#6  0x7f6591badfa9 in llvm::ScalarEvolution::getMaxBackedgeTakenCount 
(this=0x299a6e0, L=0x7) at llvm/lib/Analysis/ScalarEvolution.cpp:3390
#7  0x7f6591966040 in loopNeedsTimeoutCheck (this=, 
F=) at bytecode2llvm.cpp:363
#8  runOnFunction (this=, F=) at 
bytecode2llvm.cpp:435
#9  0x7f6591ab8166 in llvm::FPPassManager::runOnFunction (this=0x11a6ae0, 
F=...) at llvm/lib/VMCore/PassManager.cpp:1350
#10 0x7f6591ab827b in llvm::FPPassManager::runOnModule (this=0x11a6ae0, 
M=...) at llvm/lib/VMCore/PassManager.cpp:1371
#11 0x7f6591ab7d0b in llvm::MPPassManager::runOnModule (this=0x11cdab0, 
M=...) at llvm/lib/VMCore/PassManager.cpp:1424
#12 0x7f6591ab7e99 in llvm::PassManagerImpl::run (this=0x11a1dc0, M=...) at 
llvm/lib/VMCore/PassManager.cpp:1506
#13 0x7f659196dcff in generate (this=0x7fffe4746540) at 
bytecode2llvm.cpp:1411
#14 0x7f659196f85b in cli_bytecode_prepare_jit (bcs=) 
at bytecode2llvm.cpp:1826
#15 0x7f659194bec1 in cli_bytecode_prepare2 (engine=0x10fdb60, 
bcs=0x10fdc50, dconfmask=7) at bytecode.c:2353
#16 0x7f65918d0310 in cl_engine_compile (engine=0x10fdb60) at readdb.c:3112
#17 0x00407cfc in main (argc=, argv=) at clamd.c:495

** Affects: clamav (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: clamav (Ubuntu Lucid)
 Importance: Undecided
 Status: New

** Description changed:

  Binary package hint: clamav
  
  # apt-cache policy clamav-daemon
  clamav-daemon:
-   Installed: 0.96.3+dfsg-2ubuntu1.0.10.04.2
-   Candidate: 0.96.3+dfsg-2ubuntu1.0.10.04.2
+   Installed: 0.96.3+dfsg-2ubuntu1.0.10.04.2
+   Candidate: 0.96.3+dfsg-2ubuntu1.0.10.04.2
  
- 
- Since the security update of clamav, the daemon takes multiple minutes to 
load its virus database, and is causing random timeouts for users of the unix 
socket (in my case, mimedefang), trigger 400-series email temp-fails.
+ Since the security update of clamav, the daemon takes multiple minutes
+ to load its virus database, and is causing random timeouts for users of
+ the unix socket (in my case, mimedefang), trigger 400-series email temp-
+ fails.
  
  strace just shows it slowly allocating memory and not doing much else.
  
  Logs don't seem to help:
  Thu Dec 16 20:58:34 2010 -> +++ Started at Thu Dec 16 20:58:34 2010
  Thu Dec 16 20:58:34 2010 -> clamd daemon 0.96.3 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
  Thu Dec 16 20:58:34 2010 -> Log file size limit disabled.
  Thu Dec 16 20:58:34 2010 -> Reading databases from /var/lib/clamav/
  Thu Dec 16 20:58:34 2010 -> Not loading PUA signatures.
  Thu Dec 16 20:58:38 2010 -> Loaded 856324 signatures.
  
  But minutes later, it's still spinning at 100% CPU and non-responsive on
  its socket.
  
- Debug symbols seem incomplete for some reason, but here's the backtrace
- while it's stuck, FWIW:
+ Here's the backtrace while its stuck:
  
  (gdb) bt
- #0  0x7f6591bad32c in ?? () from /usr/lib/libclamav.so.6
- #1  0x7f6591bad79f in ?? () from /usr/lib/lib