Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: TestGcSys is still flaky #37331

Open
bcmills opened this issue Feb 20, 2020 · 47 comments
Open

runtime: TestGcSys is still flaky #37331

bcmills opened this issue Feb 20, 2020 · 47 comments
Assignees
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Feb 20, 2020

--- FAIL: TestGcSys (0.03s)
    gc_test.go:27: expected "OK\n", but got "using too much memory: 70486024 bytes\n"
FAIL
FAIL	runtime	50.446s

See previously #28574, #27636, #27156, #23343.

CC @mknyszek @aclements

2020-02-15T16:40:12-6917529/freebsd-amd64-race
2020-02-05T18:27:48-702226f/freebsd-amd64-race
2020-01-31T15:04:07-f2a4ab3/freebsd-amd64-race
2020-01-07T19:53:19-7d98da8/darwin-amd64-10_15
2019-12-31T12:11:24-bbd25d2/solaris-amd64-oraclerel
2019-12-11T00:01:17-9c8c27a/solaris-amd64-oraclerel
2019-11-04T15:18:34-d3660e8/plan9-386-0intro
2019-09-12T14:08:16-3d522b1/solaris-amd64-smartosbuildlet

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 20, 2020
@bcmills bcmills added this to the Backlog milestone Feb 20, 2020
@bcmills
Copy link
Member Author

bcmills commented Mar 2, 2020

@josharian
Copy link
Contributor

josharian commented Mar 3, 2020

Shall we disable the test for now?

@bcmills
Copy link
Member Author

bcmills commented Mar 16, 2020

2020-03-15T08:14:24-dc32553/freebsd-amd64-race
2020-03-04T20:52:43-c55a50e/solaris-amd64-oraclerel

@aclements, @mknyszek: what do you want to do about this test? (Do we understand the cause of these flakes?)

@mknyszek
Copy link
Contributor

mknyszek commented Mar 17, 2020

@bcmills I'll take a look.

This is usually due to some GC pacing heuristic doing something weird. A GC trace should get us part of the way there.

@mknyszek mknyszek self-assigned this Mar 17, 2020
@mknyszek
Copy link
Contributor

mknyszek commented Mar 26, 2020

OK sorry for the delay, finally looking into this now.

@mknyszek
Copy link
Contributor

mknyszek commented Mar 26, 2020

Ugh, OK. So this definitely looks like another GOMAXPROCS=1 GC pacing issue. Looking at the gctrace for a bad run on freebsd-amd64-race (which is pretty easily reproducible):

gc 1 @0.000s 1%: 0.010+0.25+0.011 ms clock, 0.010+0/0.055/0.17+0.011 ms cpu, 0->0->0 MB, 4 MB goal, 1 P (forced)
gc 2 @0.001s 3%: 0.011+0.34+0.015 ms clock, 0.011+0.15/0/0+0.015 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 3 @0.003s 4%: 0.011+0.91+0.014 ms clock, 0.011+0.15/0/0+0.014 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 4 @0.005s 4%: 0.013+0.50+0.014 ms clock, 0.013+0.15/0/0+0.014 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 5 @0.007s 5%: 0.010+0.45+0.013 ms clock, 0.010+0.15/0/0+0.013 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 6 @0.008s 6%: 0.011+0.41+0.013 ms clock, 0.011+0.14/0/0+0.013 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 7 @0.009s 7%: 0.012+0.38+0.013 ms clock, 0.012+0.14/0/0+0.013 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 8 @0.010s 7%: 0.012+0.39+0.015 ms clock, 0.012+0.16/0/0+0.015 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 9 @0.011s 8%: 0.012+0.39+0.018 ms clock, 0.012+0.14/0/0+0.018 ms cpu, 4->5->1 MB, 5 MB goal, 1 P
gc 10 @0.012s 5%: 0.012+10+0.014 ms clock, 0.012+0.059/0.13/0+0.014 ms cpu, 4->80->75 MB, 5 MB goal, 1 P
using too much memory: 70813704 bytes

You'll notice that in gc 10, we trigger the GC at the right time, but while it's happening we blow right past the hard goal.

The last time I debugged this, it was a problem with the fact that we didn't fall back to the hard goal even when we were doing more scan work than expected. It's hard for me to see how this is the case again, so there's likely something else going on. A thought: heap_scan is updated less frequently from local_scan in Go 1.14. Most of the GC work in this test comes from assists (because GOMAXPROCS=1). What if this is an issue where the runtime falls into a case where it's consistently behind on the assist ratio? It finally catches up and the assist work gets done, but it's too late. If that's the case, I'm not sure why this is basically impossible to reproduce on Linux, and easily reproducible on the freebsd-amd64-race builders.

@bcmills
Copy link
Member Author

bcmills commented May 5, 2020

@nmeum
Copy link

nmeum commented May 31, 2020

I'm not sure why this is basically impossible to reproduce on Linux, and easily reproducible on the freebsd-amd64-race builders.

I think we are also running into this on armv7 and armhf on Alpine Linux edge when building go 1.14.3:

algitbot pushed a commit to alpinelinux/aports that referenced this issue Jun 1, 2020
@mknyszek
Copy link
Contributor

mknyszek commented Nov 10, 2020

Having dug into this before, I suspect this is related to #42430 but I'm not sure in what way.

Going back to the thought I had in March (#37331 (comment)) I did change a bunch of details in this release regarding how heap_scan is updated (specifically, more often!), so that may be why the failure rate has gone down. @bcmills are those all the recent failures?

@bcmills
Copy link
Member Author

bcmills commented Nov 10, 2020

@mknyszek, those are all of the failures I could find using greplogs with the regexp FAIL: TestGcSys, yes.

@mknyszek
Copy link
Contributor

mknyszek commented Nov 11, 2020

Oh, I also want to note #40460 which is probably related. I could likely prove it with an execution trace. Will look into this soon.

@mengzhuo
Copy link
Contributor

mengzhuo commented Mar 30, 2021

@ksshannon
Copy link
Contributor

ksshannon commented Mar 31, 2021

I am getting this fairly consistently with:

go version devel +87c6fa4f47 Wed Mar 31 20:28:39 2021 +0000 darwin/amd64

and

go version devel +87c6fa4f47 Wed Mar 31 20:28:39 2021 +0000 linux/amd64

Running go test -run=GcSys -count=100 runtime , I get up to a dozen failures. Occasionally the darwin system passes, I haven't had the linux system pass.

@mknyszek
Copy link
Contributor

mknyszek commented Apr 12, 2021

Another flake on s390x builder: https://build.golang.org/log/1e93bd84feb5952dc11d951cd7acd6d949ce0277

@bcmills
Copy link
Member Author

bcmills commented Apr 23, 2021

2021-04-23T00:40:48-050b408/linux-s390x-ibm
2021-04-22T22:01:47-7405968/linux-s390x-ibm
2021-04-22T20:45:37-ecfce58/linux-s390x-ibm
2021-04-22T03:03:41-f0a8101/aix-ppc64
2021-04-21T21:25:26-7e97e4e/linux-s390x-ibm
2021-04-21T20:24:34-2550563/linux-amd64-wsl
2021-04-21T09:07:02-7735ec9/linux-amd64-wsl
2021-04-20T20:58:52-dbade77/linux-s390x-ibm
2021-04-20T15:13:47-4ce49b4/linux-s390x-ibm
2021-04-20T00:14:27-9f87943/linux-s390x-ibm
2021-04-19T21:27:43-e97d8eb/linux-s390x-ibm
2021-04-19T18:37:15-f889214/linux-s390x-ibm
2021-04-16T22:45:02-14dbd6e/linux-amd64-wsl
2021-04-16T14:15:49-0613c74/linux-arm64-packet
2021-04-14T19:32:31-bcbde83/linux-s390x-ibm
2021-04-14T13:21:14-e224787/linux-s390x-ibm
2021-04-12T17:30:21-2fa7163/linux-s390x-ibm
2021-04-10T19:02:06-a6d95b4/linux-s390x-ibm
2021-04-10T19:02:03-4638545/linux-amd64-wsl
2021-04-09T18:19:42-952187a/solaris-amd64-oraclerel
2021-04-09T15:01:13-6951da5/linux-amd64-wsl
2021-04-09T12:56:04-519f223/linux-amd64-wsl
2021-04-08T19:51:32-98dd205/aix-ppc64
2021-04-08T19:30:34-ecca94a/linux-s390x-ibm
2021-04-08T15:03:31-283b020/aix-ppc64
2021-04-08T15:03:31-283b020/solaris-amd64-oraclerel
2021-04-08T15:02:51-1be8be4/linux-s390x-ibm
2021-04-08T02:17:15-0c4a08c/aix-ppc64
2021-04-07T20:23:47-fca51ba/linux-s390x-ibm
2021-04-07T06:53:34-5d5f779/linux-arm64-packet
2021-04-07T06:53:34-5d5f779/linux-s390x-ibm
2021-04-06T18:59:08-3a30381/aix-ppc64
2021-04-05T19:15:53-e985245/linux-arm64-packet
2021-04-05T19:15:53-e985245/linux-s390x-ibm
2021-04-05T17:22:26-e617b2b/linux-s390x-ibm
2021-04-03T10:58:19-fe587ce/linux-s390x-ibm
2021-04-02T14:40:43-3651eff/linux-s390x-ibm
2021-04-02T12:44:37-a78b12a/linux-s390x-ibm
2021-04-02T05:24:14-aebc0b4/linux-s390x-ibm
2021-04-01T00:51:24-1f29e69/linux-s390x-ibm
2021-03-30T17:51:37-c40dc67/linux-s390x-ibm
2021-03-30T01:17:14-a95454b/linux-amd64-wsl
2021-03-30T00:47:22-bd6628e/linux-s390x-ibm
2021-03-29T16:48:08-2abf280/linux-s390x-ibm
2021-03-28T03:27:04-23ffb5b/linux-s390x-ibm
2021-03-25T21:35:05-374b190/linux-s390x-ibm
2021-03-25T19:21:34-2c8692d/linux-s390x-ibm
2021-03-25T14:46:50-4d66d77/linux-s390x-ibm
2021-03-23T23:08:19-769d4b6/solaris-amd64-oraclerel
2021-03-23T11:14:58-53dd0d7/linux-s390x-ibm
2021-03-23T03:49:17-b8371d4/linux-s390x-ibm
2021-03-22T17:50:42-78afca2/linux-s390x-ibm
2021-03-22T03:52:31-d8394bf/linux-s390x-ibm
2021-03-18T13:31:52-9de49ae/linux-arm64-packet
2021-03-18T03:52:02-42c25e6/linux-s390x-ibm
2021-03-17T21:24:05-7e00049/linux-amd64-wsl
2021-03-17T19:48:52-a5df883/linux-s390x-ibm
2021-03-17T03:18:12-119d76d/darwin-arm64-11_0-toothrot

@laboger
Copy link
Contributor

laboger commented Apr 23, 2021

I see this error intermittently when doing test builds on our ppc64le machines both power8 and power9.

@mknyszek
Copy link
Contributor

mknyszek commented Apr 23, 2021

Looking at this again. I was able to reproduce once on linux/amd64.

@mknyszek
Copy link
Contributor

mknyszek commented Apr 26, 2021

Of course, I've been unable to reproduce since that last failure. I will try again on the s390x builder since it seems to be more common there.

@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2021

OK finally coming back to this.

What's nice is this reproduces very readily on s390x. Hopefully I'll get somewhere.

@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2021

This is definitely #40460.

General observations:

  • GOMAXPROCS=1 in this test, so we always have 0.25 fractional worker and zero dedicated workers.
  • This test has a single heavily-allocating goroutine. I'll call it G1.
  • Most of the time, the mark work is satisfied 100% by assists. This leads to wildly incorrect pacing parameters (known issue).
  • Every time the failure happens, the heap erroneously grows beyond the goal during the GC cycle.
  • Every time the failure happens, the 0.25 fractional worker kicks in.

Every single failure always looks like the following situation :

  1. G1 starts a GC cycle after allocating a bunch. It immediately drops into a mark assist.
  2. It begins to assist, but is unable to (1) steal background credit or (2) perform enough assist work to satisfy the assist.
  3. G1, however, was preempted in all this. So it calls Gosched.
  4. The fractional worker at this point wakes up and does some work.
  5. G1 is scheduled once more, not long after, and rechecks to see if it can steal work. Turns out it can.
  6. G1 "over-steals" credit (much like how it "over-assists" to avoid calling into the assist path too much).
  7. Turns out the amount of credit it steals amounts to something like 13 MiB, far larger than the current heap goal.
  8. At this point, the fractional worker doesn't get scheduled because its scheduling policy is extremely loose, and G1 keeps allocating (13 MiB) until it runs out of credit before assisting once more and ending the GC cycle.
  9. The next GC cycle then has a much higher heap goal, but upon realizing that most of this memory is dead and the heap is actually small, the heap goal drops back to its original point.

So, what's really going wrong here? A couple things:

  1. If the fractional worker was scheduled more regularly, it would pick up the slack and the GC wouldn't last quite so long.
  2. The assist ratio is large enough that stealing 65536 units of work translates into 13 MiB of credit.

I'm going to try to figure out if there's anything specifically wrong with the assist ratio next, or if its working as intended and there's something more fundamental wrong. The former issue is much harder to fix (and wouldn't resolve this 100%).

@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2021

One other thing to notice about this is the failure always has the mark assist + fractional GC help happen at the start of a GC cycle.

So what if the situation is something like this: the fractional GC does a whole bunch of work such that there's very little work left. So the assist ratio (computed as "heap remaining / scan work remaining") ends up very large since we still have ~ 1 MiB of runway but there's very little scan work left. This is WAI and it would just be a coincidence, but unfortunately it does mean that with GOMAXPROCS=1, GC progress basically hinges on G1. That's really not ideal.

Here's a quick fix idea: what if a goroutine could never have more credit than the amount of heap runway left (basically the difference between the heap goal and the heap size at the point the assist finishes)? Then by construction a goroutine could never allocate past the heap goal without going into assist first and finishing off the GC cycle. The downside is you could have many goroutines try to end GC at the same time (go into gcMarkDone, I mean, and start trying to acquire markDoneSema), stalling the whole program a little bit as everything waits for GC to actually end. This situation should be exceedingly rare, though, and only potentially common when GOMAXPROCS=1 in which case there will only ever be 1 goroutine in gcMarkDone.

@prattmic @randall77 what do you two think?

@mknyszek
Copy link
Contributor

mknyszek commented May 11, 2021

By the way, my previous suggestion probably can't land in the freeze, even though it's fixing a bug. I don't know what to do about the flaky test until then. I think the issues causing this test to be flaky are somewhat fundamental. Do we change the test to be less flaky, then write a new one that's consistently failing due to this behavior (but turn it off)?

@bcmills any ideas?

@bcmills
Copy link
Member Author

bcmills commented May 11, 2021

@mknyszek, it's probably fine to add a call to testenv.SkipFlaky to the existing test for during the freeze.

If you have an idea for a non-flaky test that checks a similar behavior, you could maybe add the new test as a backstop against more severe regressions along with the SkipFlaky for the current test?

@mdempsky
Copy link
Member

mdempsky commented Jul 21, 2021

This test is constantly flaking for me. Does it have any value? I'm ready to mark it as broken.

@gopherbot
Copy link

gopherbot commented Jul 21, 2021

Change https://golang.org/cl/336349 mentions this issue: [dev.typeparams] runtime: mark TestGcSys as flaky

gopherbot pushed a commit that referenced this issue Jul 22, 2021
I don't know what this test is doing, but it very frequently flakes
for me while testing mundane compiler CLs. According to the issue log,
it's been flaky for ~3 years.

Updates #37331.

Change-Id: I81c43ad646ee12d4c6561290a54e4bf637695bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/336349
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
@bcmills
Copy link
Member Author

bcmills commented May 9, 2022

greplogs -l -e 'FAIL: TestGcSys' --since=2021-04-24
2022-05-06T23:11:51-7899241/linux-s390x-ibm
2022-03-03T14:29:59-7f04645/linux-amd64-wsl
2021-12-22T22:05:22-1242f43/aix-ppc64
2021-11-04T13:55:24-f58c78a/linux-arm64-packet
2021-10-06T22:28:59-b18ba59/linux-s390x-ibm
2021-08-12T21:29:44-044ec4f/linux-s390x-ibm
2021-07-25T17:16:20-849b791/linux-s390x-ibm
2021-07-12T20:58:00-a985897/linux-amd64-wsl
2021-07-02T20:11:05-287c5e8/linux-s390x-ibm
2021-07-01T18:35:33-877688c/linux-s390x-ibm
2021-07-01T17:41:22-ef8ae82/linux-s390x-ibm
2021-07-01T17:07:36-eb437ba/linux-s390x-ibm
2021-06-28T23:31:13-4bb0847/linux-s390x-ibm
2021-06-21T15:39:45-ced0fdb/linux-arm64-packet
2021-06-20T11:17:27-460900a/aix-ppc64
2021-06-18T22:05:09-9401172/linux-s390x-ibm
2021-06-16T20:37:49-6ea2af0/linux-s390x-ibm
2021-06-11T14:48:06-2721da2/linux-s390x-ibm
2021-06-08T17:24:39-0fb3e2c/aix-ppc64
2021-06-05T19:51:45-f490134/linux-amd64-wsl
2021-05-28T03:34:02-3de3440/freebsd-amd64-race
2021-05-27T18:01:11-db66e9e/linux-amd64-wsl
2021-05-27T15:00:58-950fa11/linux-s390x-ibm
2021-05-27T14:03:15-9bc5268/linux-arm64-packet
2021-05-26T18:24:48-39da9ae/linux-amd64-wsl
2021-05-26T16:11:00-bfd7798/linux-arm64-packet
2021-05-21T22:39:16-217f5dd/linux-s390x-ibm
2021-05-20T17:06:05-ce9a3b7/linux-s390x-ibm
2021-05-19T15:20:08-6c1c055/linux-s390x-ibm
2021-05-19T01:09:20-15a374d/linux-s390x-ibm
2021-05-17T18:03:56-a2c07a9/linux-s390x-ibm
2021-05-14T15:35:28-a938e52/aix-ppc64
2021-05-13T18:59:27-7a7624a/linux-arm64-packet
2021-05-13T14:52:20-2a61b3c/linux-arm64-packet
2021-05-12T15:04:42-af0f8c1/solaris-amd64-oraclerel
2021-05-10T15:48:57-0318541/linux-s390x-ibm
2021-05-07T18:14:25-af6123a/linux-s390x-ibm
2021-05-07T02:17:32-d2b0311/linux-s390x-ibm
2021-05-06T18:57:43-90d6bbb/linux-s390x-ibm
2021-05-06T15:33:43-54e20b5/linux-arm64-packet
2021-05-06T13:39:37-0e7a7a6/linux-s390x-ibm
2021-05-06T02:20:28-43c390a/linux-s390x-ibm
2021-05-05T01:48:39-caf4c94/linux-s390x-ibm
2021-05-04T23:35:34-137be77/linux-s390x-ibm
2021-05-04T18:27:33-e15d1f4/linux-s390x-ibm
2021-05-04T14:38:36-5e4f9b0/linux-s390x-ibm
2021-05-03T18:23:49-7918547/darwin-arm64-11_0-toothrot
2021-05-02T21:26:09-b177b2d/linux-s390x-ibm
2021-05-02T18:22:19-0d32d9e/linux-arm64-packet
2021-05-01T11:42:29-ffc38d8/linux-s390x-ibm
2021-04-30T19:38:25-d19eece/solaris-amd64-oraclerel
2021-04-30T18:06:38-0e315ad/linux-s390x-ibm
2021-04-29T04:19:20-42953bc/linux-s390x-ibm
2021-04-28T20:22:15-6082c05/solaris-amd64-oraclerel
2021-04-28T19:51:56-1e235cd/linux-arm64-packet
2021-04-28T17:39:34-a547625/linux-s390x-ibm
2021-04-28T17:12:39-22a56b6/linux-s390x-ibm
2021-04-28T16:13:40-5b328c4/linux-s390x-ibm
2021-04-28T02:39:09-92d1afe/linux-s390x-ibm
2021-04-27T18:17:01-bd2175e/linux-s390x-ibm
2021-04-27T16:25:40-d553c01/linux-s390x-ibm
2021-04-27T02:39:52-434e12f/linux-s390x-ibm
2021-04-26T18:42:12-8ff1da0/linux-amd64-wsl

@bcmills
Copy link
Member Author

bcmills commented May 9, 2022

This currently fails more often on unusual platforms than on first-class ones, but note that linux/arm64 is a first-class port and has a failure as recent as November, and given the failure mode I suspect that the failure on linux-amd64-wsl is representative of the test being potentially-flaky on linux/amd64 overall.

Marking as release-blocker for Go 1.19. (@golang/runtime can decide to fix the test, skip it, or delete it entirely.)

@bcmills bcmills modified the milestones: Backlog, Go1.19 May 9, 2022
@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2022

I thought we were already skipping this test? It suffers greatly from #52433.

@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2022

By that I mean skipping as of https://go.dev/cl/336349.

@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2022

Just checked on tip; the test is still skipped. How did it fail on linux-s390x-ibm at all? I'm not sure what else to do here.

@bcmills
Copy link
Member Author

bcmills commented May 10, 2022

Ah, looks like the recent failures are on release-branch.go1.17 — does the skip need to be backported?

@bcmills
Copy link
Member Author

bcmills commented May 10, 2022

@bcmills bcmills modified the milestones: Go1.19, Backlog May 10, 2022
@mknyszek
Copy link
Contributor

mknyszek commented May 10, 2022

Yeah, that skip should be backported.

@bcmills
Copy link
Member Author

bcmills commented May 10, 2022

@gopherbot, please backport to Go 1.17. This test is skipped on the main branch, but still failing semi-regularly on the release branch.

@gopherbot
Copy link

gopherbot commented May 10, 2022

Backport issue(s) opened: #52826 (for 1.17).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@gopherbot
Copy link

gopherbot commented May 18, 2022

Change https://go.dev/cl/406974 mentions this issue: [release-branch.go1.17] runtime: mark TestGcSys as flaky

gopherbot pushed a commit that referenced this issue May 18, 2022
I don't know what this test is doing, but it very frequently flakes
for me while testing mundane compiler CLs. According to the issue log,
it's been flaky for ~3 years.

Updates #37331.
Fixes #52826.

Change-Id: I81c43ad646ee12d4c6561290a54e4bf637695bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/336349
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit d8ceb13)
Reviewed-on: https://go-review.googlesource.com/c/go/+/406974
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
@mknyszek
Copy link
Contributor

mknyszek commented May 18, 2022

I think we can close this again for 1.19, since the issue was on builders for an older release.

@dmitshur
Copy link
Contributor

dmitshur commented May 19, 2022

@mknyszek The test TestGcSys is still checked in on tip, but with a skip that points to this tracking issue. (Issue #52826 on the other hand was for backporting the skip to 1.17, which is indeed done now.)

I think this issue should be open (and can be in Backlog, unassigned state) if it's a goal to eventually figure out how the test can be made non-flaky, or the test can be deleted if it's not needed and then it's fine to close this issue. What do you think?

@mknyszek
Copy link
Contributor

mknyszek commented May 20, 2022

Ah good point @dmitshur. Reopening.

@mknyszek mknyszek reopened this May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests