stable ordering of test output

Matt Harbison mharbison72 at gmail.com
Thu Apr 13 21:36:48 EDT 2017


On Thu, 13 Apr 2017 16:17:34 -0400, Augie Fackler <raf at durin42.com> wrote:

> On Thu, Apr 13, 2017 at 3:55 PM, Augie Fackler <raf at durin42.com> wrote:
>> On Wed, Mar 8, 2017 at 10:44 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>>> On Tue, 7 Mar 2017 17:56:58 +0100, Pierre-Yves David wrote:
>>>> On the other hand, this is probably not so bundle2 specific. We have
>>>> some "select" logic to read stdout and stderr as soon as possible.  
>>>> This
>>>> is the main suspect as it is possible that this logic behave different
>>>> under linux and other unix (not too much effort have been put into  
>>>> it).
>>>
>>> posix.poll() waits every type of operation no matter if fd is e.g.  
>>> writable
>>> or not. IIRC, this doesn't always work on FreeBSD since the underlying  
>>> resource
>>> of read/write ends might be shared in the kernel.
>>>
>>> But I don't think this is the source of the unstable output.
>>
>> I've had a little time today between things to try and debug this.
>> What I've found so far:
>>
>> 1) when the test passes, the remote: output is printed by the
>> _forwardoutput method in sshpeer, presumably since stderr makes it to
>> the client before the close of stdout.
>> 2) When the test fails (as on BSD, and I guess Solaris), the client
>> notices that stdout closed before stderr. It then aborts the
>> transaction and sshpeer.cleanup() notices some data chilling on stderr
>> and ensures it gets read and printed.
>>
>> I'm not really sure why BSD systems would be quicker at communicating
>> the closed FD than other systems. I'm poking at dummyssh now to see if
>> maybe it's weirdness from there...
>
> Here's a patch that seems to work. I'm not happy about it, but it
> makes the behavior consistent, and it looks mostly harmless.

This fixes it for Windows too.  Thanks!

> # HG changeset patch
> # User Augie Fackler <augie at google.com>
> # Date 1492114180 14400
> #      Thu Apr 13 16:09:40 2017 -0400
> # Node ID ec81fd7580f3e31aa92e8834ffbcf2a8e80e72e3
> # Parent  35afb54dbb4df2975dbbf0e1525b98611f18ba85
> sshpeer: try harder to snag stderr when stdout closes unexpectedly
>
> Resolves test failures on FreeBSD, but I'm not happy about the fix.
>
> diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
> --- a/mercurial/sshpeer.py
> +++ b/mercurial/sshpeer.py
> @@ -110,9 +110,17 @@ class doublepipe(object):
>              if mainready:
>                  meth = getattr(self._main, methname)
>                  if data is None:
> -                    return meth()
> +                    r = meth()
>                  else:
> -                    return meth(data)
> +                    r = meth(data)
> +                if not r and data != 0:
> +                    # We've observed a condition that indicates the
> +                    # stdout closed unexpectedly. Check stderr one
> +                    # more time and snag anything that's there before
> +                    # letting anyone know the main part of the pipe
> +                    # closed prematurely.
> +                    _forwardoutput(self._ui, self._side)
> +                return r
>
>      def close(self):
>          return self._main.close()
> _______________________________________________
> 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