(Bisected with HEAD at 042662948d804d24 (bad) and good at 62d50411dcc92cd (hadn't updated/run the tests for a few weeks.))
It's a bit of a mess, though, it doesn't fail completely reliably and not always quite the same way. Here's a log of a few examples: http://smrk.net/tmp/imapd.t.failures Reverting 13a2088c74fd (readding EV_CLEAR) I got 12 passing imapd.t runs in a row (as well as a full passing `make test` run), removing EV_CLEAR again I got 3 passes, 1 fail, and in the 5th run it just hung (another time it managed to complete 10 imapd.t runs with just 2 fails and no hang). It also leaves behind funny processes like this: ooo# ps -f -U pi PID TT STAT TIME COMMAND 60002 p1 I+p 0:00.05 sh 69047 p1 R/1 20:06.56 perl: -watch quitting quitting (perl) 27951 p1 R/1 33:06.54 - perl: (perl) 5020 p1 I 0:00.09 `-- /usr/local/bin/git --git-dir=watchimap/all.git -c core.abbrev=no 83900 p1 R/0 14:18.88 perl: -watch quitting quitting (perl) 85123 p1 R/0 27:28.68 - perl: UID:4 inbox.i1.0 imap://[::1]:21825 quitting quitting quitting quitting quitting quitting quitting quitting quitting quitting quitting qui 78162 p1 I 0:00.17 `-- /usr/local/bin/git --git-dir=watchimap/all.git -c core.abbrev=no which, given the hangs, makes me wonder if it's bumping into some kind of resource limit? (These tests were run on an OpenBSD development snapshot, not a release, but given that reverting the change makes the problem disappear I hope that doesn't matter.) -- Štěpán
