building go 1.14.4 on CentOS 7 multiple test failures

[ajn...@gmail.com]

Hi

I am attempting to build go v 1.14.4 from the git repo.  I first built version 1.4 without issue and the build itself seems fine however many of the tests fail, see the attached log.

The OS is latest CentOS 7, and go-1.4 was built using gcc 8.3.1

any pointers gratefully received

[Ian Lance Taylor]

The failures seem to be timeouts, and the reported times seem
unusually long. Are you running on an unusually slow system?

If so, you could try setting the environment variable
GO_TEST_TIMEOUT_SCALE=4 (or some other values) to tell the tests that
your system is slow.

Ian

[Alastair Neil]

It's an old but not an especially slow machine: dual 8 core E5-2670 Xeon  with 64 GB Ram.

I wil try

GO_TEST_TIMEOUT_SCALE=4

[Alastair Neil]

On Friday, 10 July 2020 14:24:54 UTC-4, Ian Lance Taylor wrote:

Thanks Ian that resulted in a considerable improvement however still failing tin the time test

--- FAIL: TestTicker (3.40s)
tick_test.go:79: saw 5 errors
tick_test.go:37: 10 20ms ticks took 800.863193ms, expected [240ms,360ms]
tick_test.go:37: 10 20ms ticks took 796.845457ms, expected [240ms,360ms]
tick_test.go:37: 10 20ms ticks took 700.044069ms, expected [240ms,360ms]
tick_test.go:37: 10 20ms ticks took 599.839176ms, expected [240ms,360ms]
tick_test.go:37: 10 20ms ticks took 499.717239ms, expected [240ms,360ms]
FAIL
FAIL time 15.827s

 

[David Riley]

On Jul 10, 2020, at 3:02 PM, Alastair Neil <ajnei...@gmail.com> wrote:
>
>
> It's an old but not an especially slow machine: dual 8 core E5-2670 Xeon with 64 GB Ram.
> I wil try
> GO_TEST_TIMEOUT_SCALE=4

I've successfully built on an older and slower (pre-Nehalem) 8-core Xeon with a similar RAM load just last week, so it's probably not that.

Is something amiss with your system's timer setup? The tick tests seem wrong, but precisely near 100ms boundaries. It almost looks like you have 10 Hz scheduler ticks and it's not seeing the granularity it should (and maybe getting scheduled later than expected).


- Dave

[Alastair Neil]

I'm not sure how I would check do you have suggestions? Also, is there a way to just run the failing test rather than redoing the whole build?  Documentation on the build process seems sparse.

[Ian Lance Taylor]

On Fri, Jul 10, 2020 at 1:19 PM Alastair Neil <ajnei...@gmail.com> wrote:
>
> I'm not sure how I would check do you have suggestions? Also, is there a way to just run the failing test rather than redoing the whole build? Documentation on the build process seems sparse.

To run the time package tests as the build does, run "go test -test.short time".

Ian

> On Friday, 10 July 2020 15:54:02 UTC-4, David Riley wrote:
>>
>> On Jul 10, 2020, at 3:02 PM, Alastair Neil <ajnei...@gmail.com> wrote:
>> >
>> >
>> > It's an old but not an especially slow machine: dual 8 core E5-2670 Xeon with 64 GB Ram.
>> > I wil try
>> > GO_TEST_TIMEOUT_SCALE=4
>>
>> I've successfully built on an older and slower (pre-Nehalem) 8-core Xeon with a similar RAM load just last week, so it's probably not that.
>>
>> Is something amiss with your system's timer setup? The tick tests seem wrong, but precisely near 100ms boundaries. It almost looks like you have 10 Hz scheduler ticks and it's not seeing the granularity it should (and maybe getting scheduled later than expected).
>>
>>
>> - Dave
>>
>>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/63a1d572-695c-462b-a83b-b37d916c512bo%40googlegroups.com.