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*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:186
#1 find<__gnu_cxx::__normal_iterator<llvm::BasicBlock* const*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:4224
#2 llvm::LoopBase<llvm::BasicBlock, llvm::Loop>::contains (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
at ./llvm/include/llvm/Analysis/LoopInfo.h:108
#3 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
at llvm/lib/Analysis/ScalarEvolution.cpp:3612
#4 0x00007f6591bad79f in llvm::ScalarEvolution::ComputeBackedgeTakenCount
(this=0x1a9f300, L=0x1466740)
at llvm/lib/Analysis/ScalarEvolution.cpp:3542
#5 0x00007f6591badaa5 in llvm::ScalarEvolution::getBackedgeTakenInfo
(this=0x1a9f300, L=0x1466740) at llvm/lib/Analysis/ScalarEvolution.cpp:3415
#6 0x00007f6591badfa9 in llvm::ScalarEvolution::getMaxBackedgeTakenCount
(this=0x299a6e0, L=0x7) at llvm/lib/Analysis/ScalarEvolution.cpp:3390
#7 0x00007f6591966040 in loopNeedsTimeoutCheck (this=<value optimized out>,
F=<value optimized out>) at bytecode2llvm.cpp:363
#8 runOnFunction (this=<value optimized out>, F=<value optimized out>) at
bytecode2llvm.cpp:435
#9 0x00007f6591ab8166 in llvm::FPPassManager::runOnFunction (this=0x11a6ae0,
F=...) at llvm/lib/VMCore/PassManager.cpp:1350
#10 0x00007f6591ab827b in llvm::FPPassManager::runOnModule (this=0x11a6ae0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1371
#11 0x00007f6591ab7d0b in llvm::MPPassManager::runOnModule (this=0x11cdab0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1424
#12 0x00007f6591ab7e99 in llvm::PassManagerImpl::run (this=0x11a1dc0, M=...) at
llvm/lib/VMCore/PassManager.cpp:1506
#13 0x00007f659196dcff in generate (this=0x7fffe4746540) at
bytecode2llvm.cpp:1411
#14 0x00007f659196f85b in cli_bytecode_prepare_jit (bcs=<value optimized out>)
at bytecode2llvm.cpp:1826
#15 0x00007f659194bec1 in cli_bytecode_prepare2 (engine=0x10fdb60,
bcs=0x10fdc50, dconfmask=7) at bytecode.c:2353
#16 0x00007f65918d0310 in cl_engine_compile (engine=0x10fdb60) at readdb.c:3112
#17 0x0000000000407cfc in main (argc=<value optimized out>, argv=<value
optimized out>) 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 0x00007f6591bad32c in ?? () from /usr/lib/libclamav.so.6
- #1 0x00007f6591bad79f in ?? () from /usr/lib/libclamav.so.6
- #2 0x00007f6591badaa5 in ?? () from /usr/lib/libclamav.so.6
- #3 0x00007f6591badfa9 in ?? () from /usr/lib/libclamav.so.6
- #4 0x00007f6591966040 in ?? () from /usr/lib/libclamav.so.6
- #5 0x00007f6591ab8166 in ?? () from /usr/lib/libclamav.so.6
- #6 0x00007f6591ab827b in ?? () from /usr/lib/libclamav.so.6
- #7 0x00007f6591ab7d0b in ?? () from /usr/lib/libclamav.so.6
- #8 0x00007f6591ab7e99 in ?? () from /usr/lib/libclamav.so.6
- #9 0x00007f659196dcff in ?? () from /usr/lib/libclamav.so.6
- #10 0x00007f659196f85b in ?? () from /usr/lib/libclamav.so.6
- #11 0x00007f659194bec1 in cli_bytecode_prepare2 () from
/usr/lib/libclamav.so.6
- #12 0x00007f65918d0310 in cl_engine_compile () from /usr/lib/libclamav.so.6
- #13 0x0000000000407cfc in main (argc=<value optimized out>, argv=<value
optimized out>) at clamd.c:495
+ #0 __find<__gnu_cxx::__normal_iterator<llvm::BasicBlock* const*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:186
+ #1 find<__gnu_cxx::__normal_iterator<llvm::BasicBlock* const*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:4224
+ #2 llvm::LoopBase<llvm::BasicBlock, llvm::Loop>::contains (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
+ at ./llvm/include/llvm/Analysis/LoopInfo.h:108
+ #3 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
+ at llvm/lib/Analysis/ScalarEvolution.cpp:3612
+ #4 0x00007f6591bad79f in llvm::ScalarEvolution::ComputeBackedgeTakenCount
(this=0x1a9f300, L=0x1466740)
+ at llvm/lib/Analysis/ScalarEvolution.cpp:3542
+ #5 0x00007f6591badaa5 in llvm::ScalarEvolution::getBackedgeTakenInfo
(this=0x1a9f300, L=0x1466740) at llvm/lib/Analysis/ScalarEvolution.cpp:3415
+ #6 0x00007f6591badfa9 in llvm::ScalarEvolution::getMaxBackedgeTakenCount
(this=0x299a6e0, L=0x7) at llvm/lib/Analysis/ScalarEvolution.cpp:3390
+ #7 0x00007f6591966040 in loopNeedsTimeoutCheck (this=<value optimized out>,
F=<value optimized out>) at bytecode2llvm.cpp:363
+ #8 runOnFunction (this=<value optimized out>, F=<value optimized out>) at
bytecode2llvm.cpp:435
+ #9 0x00007f6591ab8166 in llvm::FPPassManager::runOnFunction (this=0x11a6ae0,
F=...) at llvm/lib/VMCore/PassManager.cpp:1350
+ #10 0x00007f6591ab827b in llvm::FPPassManager::runOnModule (this=0x11a6ae0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1371
+ #11 0x00007f6591ab7d0b in llvm::MPPassManager::runOnModule (this=0x11cdab0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1424
+ #12 0x00007f6591ab7e99 in llvm::PassManagerImpl::run (this=0x11a1dc0, M=...)
at llvm/lib/VMCore/PassManager.cpp:1506
+ #13 0x00007f659196dcff in generate (this=0x7fffe4746540) at
bytecode2llvm.cpp:1411
+ #14 0x00007f659196f85b in cli_bytecode_prepare_jit (bcs=<value optimized
out>) at bytecode2llvm.cpp:1826
+ #15 0x00007f659194bec1 in cli_bytecode_prepare2 (engine=0x10fdb60,
bcs=0x10fdc50, dconfmask=7) at bytecode.c:2353
+ #16 0x00007f65918d0310 in cl_engine_compile (engine=0x10fdb60) at
readdb.c:3112
+ #17 0x0000000000407cfc in main (argc=<value optimized out>, argv=<value
optimized out>) at clamd.c:495
** Also 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
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.
+ 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*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:186
#1 find<__gnu_cxx::__normal_iterator<llvm::BasicBlock* const*,
std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> > >,
llvm::BasicBlock const*> (this=0x1a9f300, L=0x1466740, ExitingBlock=<value
optimized out>) at /usr/include/c++/4.4/bits/stl_algo.h:4224
#2 llvm::LoopBase<llvm::BasicBlock, llvm::Loop>::contains (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
- at ./llvm/include/llvm/Analysis/LoopInfo.h:108
+ at ./llvm/include/llvm/Analysis/LoopInfo.h:108
#3 llvm::ScalarEvolution::ComputeBackedgeTakenCountFromExit (this=0x1a9f300,
L=0x1466740, ExitingBlock=<value optimized out>)
- at llvm/lib/Analysis/ScalarEvolution.cpp:3612
+ at llvm/lib/Analysis/ScalarEvolution.cpp:3612
#4 0x00007f6591bad79f in llvm::ScalarEvolution::ComputeBackedgeTakenCount
(this=0x1a9f300, L=0x1466740)
- at llvm/lib/Analysis/ScalarEvolution.cpp:3542
+ at llvm/lib/Analysis/ScalarEvolution.cpp:3542
#5 0x00007f6591badaa5 in llvm::ScalarEvolution::getBackedgeTakenInfo
(this=0x1a9f300, L=0x1466740) at llvm/lib/Analysis/ScalarEvolution.cpp:3415
#6 0x00007f6591badfa9 in llvm::ScalarEvolution::getMaxBackedgeTakenCount
(this=0x299a6e0, L=0x7) at llvm/lib/Analysis/ScalarEvolution.cpp:3390
#7 0x00007f6591966040 in loopNeedsTimeoutCheck (this=<value optimized out>,
F=<value optimized out>) at bytecode2llvm.cpp:363
#8 runOnFunction (this=<value optimized out>, F=<value optimized out>) at
bytecode2llvm.cpp:435
#9 0x00007f6591ab8166 in llvm::FPPassManager::runOnFunction (this=0x11a6ae0,
F=...) at llvm/lib/VMCore/PassManager.cpp:1350
#10 0x00007f6591ab827b in llvm::FPPassManager::runOnModule (this=0x11a6ae0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1371
#11 0x00007f6591ab7d0b in llvm::MPPassManager::runOnModule (this=0x11cdab0,
M=...) at llvm/lib/VMCore/PassManager.cpp:1424
#12 0x00007f6591ab7e99 in llvm::PassManagerImpl::run (this=0x11a1dc0, M=...)
at llvm/lib/VMCore/PassManager.cpp:1506
#13 0x00007f659196dcff in generate (this=0x7fffe4746540) at
bytecode2llvm.cpp:1411
#14 0x00007f659196f85b in cli_bytecode_prepare_jit (bcs=<value optimized
out>) at bytecode2llvm.cpp:1826
#15 0x00007f659194bec1 in cli_bytecode_prepare2 (engine=0x10fdb60,
bcs=0x10fdc50, dconfmask=7) at bytecode.c:2353
#16 0x00007f65918d0310 in cl_engine_compile (engine=0x10fdb60) at
readdb.c:3112
#17 0x0000000000407cfc in main (argc=<value optimized out>, argv=<value
optimized out>) at clamd.c:495
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691414
Title:
clamav taking extremely long time to load database
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
