Go: plugin: program on linux/s390x sometimes hangs after calling "plugin.Open" [1.15 backport]
@mundaym requested issue #40473 to be considered for backport to the next 1.15 minor release.
@gopherbot please open backport issues.
This is a bug that causes programs to intermittently crash with no workaround.
gopherbot
All 7 comments
Change https://golang.org/cl/248478 mentions this issue: [release-branch.go1.15] cmd/internal/obj: fix inline marker issue on s390x
gopherbot
on 14 Aug 2020
Approving per discussion in a release meeting. This backport applies to both 1.15 (this issue) and 1.14 (#40694).
dmitshur
on 3 Sep 2020
@dmitshur Why was this bumped to 1.15.3? This bug is causing a real problem for a user and the fix has been ready to go for quite some time. I'd have appreciated some sort of warning if there was a reason it was going to miss the cutoff.
mundaym
on 10 Sep 2020
I generally don't use release blocker tags because we aren't supposed to for the non-first class ports. Should I start doing that if I feel an issue needs to be resolved? Alternatively bumping issue milestones a week or so earlier would give me time to start a discussion if I feel it shouldn't be bumped.
EDIT: I've created a golang-dev post for discussion: https://groups.google.com/g/golang-dev/c/6b-rdo-i8sA
mundaym
on 10 Sep 2020
I've answered more generally on the thread. The two backport CLs need to be reviewed, as they can't be submitted without a +2. Could you please find a code reviewer for them? Thank you.
dmitshur
on 10 Sep 2020
Could you please find a code reviewer for them? Thank you.
For what it's worth, I disagree with this - if an external contributor is going through the extra trouble of sending fixes and backporting them for a bugfix release, we shouldn't rely on them to stay on top of the CL for multiple days or even weeks until it finally gets a review.
I personally think that, since we have https://dev.golang.org/owners and the release team already goes over all backport issues during the release process, it wouldn't be a lot of added work to simply ping the owners for a review of each backport CL well before the release is due. I imagine that should be enough for the vast majority of cases - if someone is listed as a package owner, I would argue that their top priority is reviewing and shipping critical bug fixes.
mvdan
on 10 Sep 2020
Closed by merging bbee5236cd64a11a2bfd194eb9f809f51cae0870 to release-branch.go1.15.
gopherbot
on 10 Sep 2020
Related issues
dominikh
路
3Comments
bradfitz
路
3Comments
go101
路
3Comments
lkarlslund
路
3Comments
stub42
路
3Comments
Most helpful comment
For what it's worth, I disagree with this - if an external contributor is going through the extra trouble of sending fixes and backporting them for a bugfix release, we shouldn't rely on them to stay on top of the CL for multiple days or even weeks until it finally gets a review.
I personally think that, since we have https://dev.golang.org/owners and the release team already goes over all backport issues during the release process, it wouldn't be a lot of added work to simply ping the owners for a review of each backport CL well before the release is due. I imagine that should be enough for the vast majority of cases - if someone is listed as a package owner, I would argue that their top priority is reviewing and shipping critical bug fixes.