On 29/03/2010 23:44, Scott Ellis wrote:
>
> Your backtrace looks exactly like what I see on 2.0Beta4 on NetBSD, and I
> observed the same thing with respect to imap_zlib. I just can't find the
> smoking gun that links the process behavior with the use of imap_zlib. :-/
>
> At least I'm not the o
[snip]
> I am pretty sure it is related to imap_zlib ... at least this did not
> happen when I disabled the plugin.
>
[snip]
Your backtrace looks exactly like what I see on 2.0Beta4 on NetBSD, and I
observed the same thing with respect to imap_zlib. I just can't find the
smoking gun that links th
On 21.03.2010 15:17, Timo Sirainen wrote:
Hi Timo,
It would be helpful to find out what the I/O function is that is being
called. For example:
b ioloop-epoll.c:208
p *io
cont
p *io
cont
..etc..
What is the *io output? If it's client_output() or something else as
generic.. Use "step" to get in
On 21.03.2010 15:17, Timo Sirainen wrote:
Hi,
strace -p shows a repeating pattern of
epoll_wait(8, {{EPOLLOUT, {u32=36560672, u64=36560672}}}, 5, 4872) = 1
gettimeofday({1269133967, 495298}, NULL) = 0
gettimeofday({1269133967, 495333}, NULL) = 0
gettimeofday({1269133967, 495370}, NULL) = 0
On Sun, 2010-03-21 at 01:20 +, Bernhard Schmidt wrote:
> strace -p shows a repeating pattern of
>
> epoll_wait(8, {{EPOLLOUT, {u32=36560672, u64=36560672}}}, 5, 4872) = 1
> gettimeofday({1269133967, 495298}, NULL) = 0
> gettimeofday({1269133967, 495333}, NULL) = 0
> gettimeofday({1269133967,
Hi,
since a couple of weeks I occasionally have an imapd going crazy on me,
using up 100% CPU. Current revision is 10962
29865 vmail 20 0 47820 3296 1708 R 99.7 0.9 131:07.85 imap
vmail29865 86.1 0.8 47820 3296 ?RMar20 131:20
dovecot/imap [berni 2001:a60:f001:1:219:66ff
