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. ScottE
On 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.
Is this solved by now? (imap_zlib plugin bug?) On Thu, 2010-03-25 at 19:47 -0700, 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. > > 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. > > ScottE >