I'm also seeing something that appears to be similar. Here's what I got for a backtrace:
gdb /usr/local/sbin/clamav-milter 151 (gdb) where #0 0x282692f4 in _init () from /usr/lib/libc_r.so.4 #1 0x282899d2 in popen () from /usr/lib/libc_r.so.4 #2 0x80510fb in getopt () #3 0x28244ddb in mi_clr_macros () from /usr/lib/libmilter.so.2 #4 0x282442c4 in mi_engine () from /usr/lib/libmilter.so.2 #5 0x28243f3d in mi_handle_session () from /usr/lib/libmilter.so.2 #6 0x282436f2 in mi_thread_handle_wrapper () from /usr/lib/libmilter.so.2 #7 0x2826c240 in _thread_start () from /usr/lib/libc_r.so.4 #8 0xbfa98ffc in ?? () (gdb) info threads * 1 process 151, thread 1 0x282692f4 in _init () from /usr/lib/libc_r.so.4 When I stopped it, the clamav-milter process was chewing up cpu: 151 clamav 64 0 80060K 77832K RUN 1 38:27 58.30% 58.30% clamav-milter Michael Grant On 8/12/07, Török Edvin <[EMAIL PROTECTED]> wrote: > On 8/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Sorry for all the replies to myself, but don't know if any of this > > info might be helpful. I thought I'd try to keep 0.91.1 going, and if > > it hosed again, run a dtrace (at least the dtruss script from the > > DTraceToolkit) to see what was going on. It hung again, but I don't > > know if any of this output is of any use. I saw a ton of lwp_park > > calls and nothing really else. Like this: > > > > It would be mroe useful if you could get a backtrace of all running threads. > Use a debugger (like gdb) to do that. > In case of gdb, just attach to the running process, and do a 'thread > apply all bt'. > > --Edwin > _______________________________________________ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://lurker.clamav.net/list/clamav-users.html > > _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
