[PATCH windows] tests: add and remove some (glob) markers

[Matt Harbison]

On Sat, 16 Sep 2017 01:14:10 -0400, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> On Fri, 15 Sep 2017 22:14:31 -0400, Augie Fackler <raf at durin42.com>  
> wrote:
>
>>
>>> On Sep 15, 2017, at 22:08, Augie Fackler <raf at durin42.com> wrote:
>>>
>>> # HG changeset patch
>>> # User Augie Fackler <augie at 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