On Sat, 16 Sep 2017 01:14:10 -0400, Matt Harbison <mharbiso...@gmail.com>
wrote:
On Fri, 15 Sep 2017 22:14:31 -0400, Augie Fackler <r...@durin42.com>
wrote:
On Sep 15, 2017, at 22:08, Augie Fackler <r...@durin42.com> wrote:
# HG changeset patch
# User Augie Fackler <au...@google.com>
# Date 1505527705 14400
# Fri Sep 15 22:08:25 2017 -0400
# Node ID 0da0e691552a428641c75e1633e5f1d0fbf3483e
# Parent 209120041d12b524648fa856732aa404dfedd91d
tests: add and remove some (glob) markers
These are the sane-looking failures on the Windows buildbot. The
run-tests failure looks like some sort of environment variable setting
dance is failing on Windows (huh?), and I'm singularly baffled by the
test-patchbomb-tls.t failure. But we're close to getting that builder
to pass.
I'm baffled by the run-tests failure too. The test runs fine outside of
buildbot on that system. Any chance you can force a debug run of this
test, to see what is lurking behind $RUNTESTDIR?
The patchbomb test failure is transient. I've seen cases where `hg
serve` daemons from the previous run aren't killed for some reason.
Aside from subsequent serve errors, a telltale sign is the warnings in
the build phase dropping from 7 to 1, as the C code isn't rebuilt.
(Compare before[1] and after[2] the Patch Tuesday reboot.) When I
notice that, I have to manually kill off the stuck python process. But
sometimes there is no stuck process, and these *.t errors clear on their
own. I wonder if the serve process looks like it is running to the
parent process, which stops waiting, but it hasn't opened the listening
port yet when a test process tries to connect.
I'll check Monday to see if python processes are stuck.
Yep, two stale processes needed to be killed.
The interesting thing is I used ProcessExplorer to track them down, and
CWD for them was a *.t directory with nothing in it other than an empty
'error.log'. (Both processes were using this file, apparently.) So I
hacked killdaemons.py to accept a pid on the command line instead of
reading the file, and both terminated successfully. It's like the pid
file was never processed (or empty) before deletion. A few months ago, I
was able to consistently reproduce a case where a test ran, the serve
process didn't exit, but I could kill it with the pid file left by the
test. It stopped happening the next day, but there's definitely flakiness
in this area.
Also, $RUNTESTDIR for these was the literal expected in the run-test
failure.
[1]
https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/181/steps/make%20local/logs/stdio
[2]
https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/183/steps/make%20local/logs/stdio
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
