Agreed. I think there is a deep problem, but the deep problem is here
rather than in the Go tests.
thanks
Dan
On Mon, 2017-10-02 at 18:16 -0700, Ian Lance Taylor wrote:
> 10 minutes is the default timeout, so that's why that run failed.
>
> 5 minutes, the time shown above, is an extraordinarily
On Mon, Oct 2, 2017 at 5:51 PM, Dan Kortschak
wrote:
>
> Trying today, the roles of the machines have reversed; the one failing
> on Friday passed today and vice versa. The passing test:
>
> ```
> $ time go test -test.short cmd/go
> ok cmd/go 339.070s
>
> real5m45.804s
> user1m38.821
Trying today, the roles of the machines have reversed; the one failing
on Friday passed today and vice versa. The passing test:
```
$ time go test -test.short cmd/go
ok cmd/go 339.070s
real5m45.804s
user1m38.821s
sys 0m49.390s
```
The version is a lie - there is a change to mal
On Thu, Sep 28, 2017 at 10:12 PM, Dan Kortschak
wrote:
>
> I have just tried replicating the issue today and this time, one
> machine passes everything, while the other does not. I am beginning to
> suspect that file system loads may be a possible cause (the head node
> is quiet, but the file syst
I have just tried replicating the issue today and this time, one
machine passes everything, while the other does not. I am beginning to
suspect that file system loads may be a possible cause (the head node
is quiet, but the file system is shared across many nodes in both
cases).
The newer machine
On Thu, Sep 28, 2017 at 5:40 PM, Dan Kortschak
wrote:
>
> I can replicate this on another newer RHEL machine. In both cases the
> machines are quiet (they are the head nodes of HPC infrastructure and
> don't see a great deal of work due to the HPC use policy.
>
> I have tried building previous ver
I can replicate this on another newer RHEL machine. In both cases the
machines are quiet (they are the head nodes of HPC infrastructure and
don't see a great deal of work due to the HPC use policy.
I have tried building previous versions and see similar though
different failures going back to 1.7
On Wed, Sep 27, 2017 at 10:20 PM, Dan Kortschak
wrote:
>
> I am seeing all.bash fail when testing cmd/go with a likely cause being
> internal/poll.runtime_pollWait.
>
> I'm trying to build go1.9 (with a change to the heap size), but
> all.bash fails as shown below. Is this a known problem? and if
I am seeing all.bash fail when testing cmd/go with a likely cause being
internal/poll.runtime_pollWait.
I'm trying to build go1.9 (with a change to the heap size), but
all.bash fails as shown below. Is this a known problem? and if it is,
is there a workaround.
thanks
```
panic: test timed out af
