reflect: MethodByName().Interface() leads to fatal error: sweep increased allocation count [1.10 backport]

[gopherbot]

@randall77 requested issue #27695 to be considered for backport to the next 1.10 minor release.

@gopherbot, please open a backport issue please.

This has been broken for a while, but it's a nasty bug. We should consider backporting it.

[gopherbot]

Change https://golang.org/cl/138586 mentions this issue: [release-branch.go1.10] reflect: fix s390x reflect method calls

[gopherbot]

Change https://golang.org/cl/138585 mentions this issue: [release-branch.go1.10] reflect: ensure correct scanning of return values

[gopherbot]

Change https://golang.org/cl/138584 mentions this issue: [release-branch.go1.10] reflect: use correct write barrier operations for method funcs

[gopherbot]

Change https://golang.org/cl/138587 mentions this issue: [release-branch.go1.10] runtime: don't dereference 0-length bitvectors

[dmitshur]

@randall77 This patch does not apply cleanly to release-branch.go1.10 right now. If you still think this should be backported, can you please make a cherry-pick CL as described at https://golang.org/wiki/MinorReleases#making-cherry-pick-cls?

We can also decide this doesn't meet the backport policy criteria, since there is a workaround (update to Go 1.11.1, where this issue is resolved).

Edit: I'll move the milestone to Go 1.10.6 since it's too late for Go 1.10.5 release that's happening today.

[gopherbot]

Change https://golang.org/cl/147237 mentions this issue: [release-branch.go1.10] reflect: ensure correct scanning of return values

[bcmills]

@randall77, given the fix in 1.11 and the proximity to 1.12, is this still worth backporting to 1.10?

[FiloSottile]

This fix is backported to 1.11, and then upgrading to 1.11 will be a valid workaround, so this is not eligible for backport to 1.10.