[Dovecot] Busy looping of 2.0Beta4 on NetBSD-current
I built and install Dovecot 2.0Beta4 on my NetBSD/amd64-current system, and am seeing the user-owned imap processes busy-looping. In Dovecot 1.2.x (and 1.x and 0.x..) I force ionotify and ioloop to kqueue, so I suspected that was the problem. Turns out it's not: Using poll or none also causes the same problem.
This did not happen in 1.2.8 (didn't try anything later than that).
After a quick visit to gdb, I added some i_debug() statements in ioloop-kqueue.c (when I had that as the notify and loop method) which showed that the loop was in io_loop_handler_run() . I haven't done any similar debugging for the other ioloop methods, but a quick look at the 2.0 changelog for those files doesn't raise any immediate alarms.
Any ideas what to look for here? Timo, any ideas? 1.2.x worked perfectly so it's something "new" in 2.0.
ScottEOn 26.3.2010, at 4.47, Scott Ellis wrote:
I built and install Dovecot 2.0Beta4 on my NetBSD/amd64-current system, and am seeing the user-owned imap processes busy-looping. In Dovecot 1.2.x (and 1.x and 0.x..) I force ionotify and ioloop to kqueue, so I suspected that was the problem. Turns out it's not: Using poll or none also causes the same problem.
But it's not hanging anyway, just eating all CPU? I guess it's calling some IO_WRITE callback all the time. You could make it do something like:
i_debug("%p", io->io.callback);
just before it's called in the ioloop code. Then in gdb do "x 0x12345" for the returned address to see what function it's calling all the time.
On 3/26/2010 10:05 AM, Scott Ellis wrote:
Turns out the ioloop busy-looping was a red herring. Makes sense given that any ioloop- and ioloop-notify- configuration caused the same behavior.
I haven't figured out what specifically is broken, but the inclusion use of the imap_zlib plugin is the culprit. Not clear if it's a bug in the handling of COMPRESS, or something more internal to the use of zlib, but removing that plugin makes the symptom dissappear.
Thoughts on what to instrument? The debug file with mail_debug enabled doesn't show anything of interest by default (it looks like everything is fine, but clearly there is some client-initiated action which causes the problem).
Am open to ideas on what to try next. :-)
participants (3)
-
Scott Ellis
-
Scott Ellis
-
Timo Sirainen