Hello,
On Sunday 09 November 2008 14:53, zooko wrote:
> Good job diagnosing it, Thorkil!
Thanks!
>
> I want to clarify one detail:
>
> >> import os
> >> os.system('yes | head -n 2');
>
> > So, the two ys appear, a looping yes program can be observed with
> > top, and C-c
> > is needed to terminate. The point of this is that buildbot, as far
> > as I know,
> > is a Python program, so this may be the reason why we see this looping
> > behaviour on the Mac OS X buildbot slaves.
>
> Just to clarify -- the buildbot is a Python program which runs
> "make". The equivalent Python code would look something like this:
>
> import os
> os.system("make test")
>
> So more or less the only way that the buildbot code can affect the
> behavior of the yes process which is spawned by the test harness
> process which is spawned by the make process which is spawned by the
> buildslave process is through stdin.
>
> So I guess something about the state of stdin (open/closed? blocking/
> nonblocking setting? is a pty?) causes yes to behave this way.
You may be right here.
Recall, however, the different behaviour of yes|head -n2 run via Python on a
Linux that I described:
> $ python runCmd.py
> y
> y
> yes: standard output: Broken pipe
> yes: write error
> $
Although not easily explained, much indicates to me that something is
different in the way the pipe between yes and head is being set up. I am sure
that various intricate conditions need to be fulfilled, both on the sending
and receiving end of this pipe, for the result to appear smoothly as desired.
For example, consider the head process: When displaying the first 10 lines of
a file, it makes sense to simply close the input when done. But when getting
data from another process, through a pipe, it may make more sense to skip the
rest of the input, actively reading it, until end-of-file is met. Perhaps
this is really what happens, with end-of-file simply never occurring from the
yes process. I have not been able to detect any CPU usage of the head
process, however.
All in all, I am not too surprised that the construction turns out to be
brittle.
And by the way, presently, the issue1017 test also fails on my Linux buildbot
slave, recently cured of its lack of QuickCheck 2.1
(http://buildbot.darcs.net/buildbot-darcs/builders/thorkil%20tn9%20Linux-2.6.13-15%20SUSE-10.0%20i686/builds/219/steps/test/logs/stdio):
> Running issue1017_whatsnew_stack.sh ... FAILED!
> Output from failed issue1017_whatsnew_stack.sh:
>
> rm -rf temp1
> mkdir temp1
> cd temp1
> darcs init
> yes | head -n 4000 | xargs echo -n > foo
> yes: standard output: Broken pipe
> yes: write error
> darcs add foo
> darcs record -a -m 'foo' foo
> Recording changes in "foo":
>
> Finished recording patch 'foo'
> yes | head -n 300000 | xargs echo -n > foo
> xargs: echo: Argument list too long
> head: write error: Broken pipe
> head: write error
> yes: standard output: Broken pipe
> yes: write error
This appears to be for a different reason, however.
> ...
Best regards
Thorkil
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
