Štěpán Němec <[email protected]> wrote:
> (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).

Odd, can you confirm this is with p5-IO-KQueue installed?
(it's really slow w/o since it needs to sleep).

I saw some similar failures the other week on NetBSD, couldn't
reproduce it, and I lost power at my VM host so later forgot
about it :x

Never seen such failures on FreeBSD, though.

> 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?

Parallel tests would increase the likelyhood of limits being hit
(make check, make check-run, prove -j$N)

`make test' and 'prove -lwv' (w/o -j) are serial,
and `make check-run N=1' can force serial tests while
saving loading overhead.

> (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.)

I can't reproduce it on 7.3 (amd64), right now.
Haven't gotten around to 7.4...

Reply via email to