runtime: TestGcSys fails on arm64 #27636
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ianlancetaylor
added
the
NeedsInvestigation
|
CC @aclements |
|
Change https://golang.org/cl/135155 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 13, 2018
This failure occurs randomly on arm64. 13:10:32 --- FAIL: TestGcSys (0.06s) 13:10:32 gc_test.go:30: expected "OK\n", but got "using too much memory: 71401472 bytes\n" 13:10:32 FAIL Updates #27636 Change-Id: Ifd4cfce167d8054dc6f037bd34368d63c7f68ed4 Reviewed-on: https://go-review.googlesource.com/135155 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
|
Change https://golang.org/cl/184097 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 4, 2019
This change makes it so that if we're already finding ourselves in a situation where we've done more scan work than expected in the steady-state (that is, 50% of heap_scan for GOGC=100), then we fall back on the hard heap goal instead of continuing to assume the expected case. In some cases its possible that we're already doing more scan work than expected, and if GC assists come in just at that window where we notice it, they might accumulate way too much assist credit, causing undue heap growths if GOMAXPROCS=1 (since the fractional background worker isn't guaranteed to fire). This case seems awfully specific, and that's because it's exactly the case for TestGcSys, which has been flaky for some time as a result. Fixes #28574, #27636, and #27156. Change-Id: I771f42bed34739dbb1b84ad82cfe247f70836031 Reviewed-on: https://go-review.googlesource.com/c/go/+/184097 Run-TryBot: Michael Knyszek <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Keith Randall <[email protected]>
|
This should be fixed now as of aae0b5b. |
t4n6a1ka
pushed a commit
to t4n6a1ka/go
that referenced
this issue
Sep 5, 2019
This change makes it so that if we're already finding ourselves in a situation where we've done more scan work than expected in the steady-state (that is, 50% of heap_scan for GOGC=100), then we fall back on the hard heap goal instead of continuing to assume the expected case. In some cases its possible that we're already doing more scan work than expected, and if GC assists come in just at that window where we notice it, they might accumulate way too much assist credit, causing undue heap growths if GOMAXPROCS=1 (since the fractional background worker isn't guaranteed to fire). This case seems awfully specific, and that's because it's exactly the case for TestGcSys, which has been flaky for some time as a result. Fixes golang#28574, golang#27636, and golang#27156. Change-Id: I771f42bed34739dbb1b84ad82cfe247f70836031 Reviewed-on: https://go-review.googlesource.com/c/go/+/184097 Run-TryBot: Michael Knyszek <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Keith Randall <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
13:10:32 --- FAIL: TestGcSys (0.06s)
13:10:32 gc_test.go:30: expected "OK\n", but got "using too much memory: 71401472 bytes\n"
13:10:32 FAIL
This failure occurs randomly on arm64, skipping this test just like Windows does.
The text was updated successfully, but these errors were encountered: