Transient Windows test failures

Augie Fackler raf at durin42.com
Sun Jun 18 22:19:29 EDT 2017


> On Jun 16, 2017, at 22:02, Matt Harbison <mharbison72 at gmail.com> wrote:
> 
> On Fri, 16 Jun 2017 09:59:30 -0400, Augie Fackler <raf at durin42.com> wrote:
> 
>> On Fri, Jun 16, 2017 at 12:18:18AM -0400, Matt Harbison wrote:
>>> So apparently, this is a symptom of not having %SystemRoot% in the
>>> environment when calling CreateProcess().
>>> 
>>> https://bugs.python.org/issue13524
>>> https://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/
>>> 
>>> I see that setup.py special cases this variable.  I did a search for 'env
>>> =', and it looks like hooks and pager start with empty environments, so they
>>> must not inherit this.  IDR if any recent changes were made that start with
>>> an empty environment.
>>> 
>>> The thing I can't get my mind around is the hit and miss nature of the
>>> error, if this is really the problem.
>> 
>> It sounds like it should be harmless to just always forward
>> %SystemRoot% - should we just do that?
> 
> Seems reasonable, but run-tests._getenv() already does an os.environ.copy(), so it should be there?
> 
> It does seem like a good idea to do it for hooks and other things executed, where the environment is built from scratch.  The question is where?  There's util.popen[2-4](), plus some direct calls to subprocess.Popen(), and an os.system().  I considered util.shellenviron(), but there are far fewer calls to this than places where processes are spawned.

My gut (without having gone through the calls) is that we should probably build up a subproc module in hg and standardize the various ways we call things - right now it's kind of messy, and I strongly suspect we only need 2 or 3 functions (naive call, call with stdin/stdout/stderr wired up, call with no stdin but stdout/stderr captured).

Absent that cleanup, yeah, just do the necessary cleanup on each callsite - the os.system() call should (I think) forward everything though, so that one at least should be fine...


> I just hit it here:
> 
> --- c:/Users/Matt/projects/hg/tests/test-log.t
> +++ c:/Users/Matt/projects/hg/tests/test-log.t.err
> @@ -1476,72 +1476,64 @@
>   $ hg resolve -m foo
>   (no more unresolved files)
>   $ hg ci -m "First merge, related"
> +  abort: Invalid Signature
> +  [255]
> 
> I was wondering if it's right on the edge of some limit, and paths or whatever being set by the test runner are (sometimes) pushing it out of the environment block.  But the docs say there's no limit to the block size:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
> 
>>> _______________________________________________
>>> Mercurial-devel mailing list
>>> Mercurial-devel at mercurial-scm.org
>>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list