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: pcdata is -2 and 12 locals stack map entries error on nil pointer [1.15 backport] #40742

Open
randall77 opened this issue Aug 12, 2020 · 7 comments

Comments

@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 12, 2020

@randall77 requested issue #40629 to be considered for backport to the next 1.15 minor release.

This patch:

+++ b/src/cmd/compile/internal/ssa/func.go
@@ -274,6 +274,9 @@ func (f *Func) freeValue(v *Value) {
        if len(v.Args) != 0 {
                f.Fatalf("value %s still has %d args", v, len(v.Args))
        }
+       if v == f.LastDeferExit {
+               println("FREEING THE LASTDEFEREXIT")
+       }
        // Clear everything but ID (which we reuse).
        id := v.ID

triggers a bunch of times during make.bash. Both 1.14.2 and tip. Looks like we need to fix this for the release - I think we're just getting lucky that we don't stack copy or gc trace such cases normally (stack copy is only likely to happen with an unrecovered panic?), or that the random other instruction's liveness map is correct (or good enough).

@gopherbot gopherbot added this to the Go1.15.1 milestone Aug 12, 2020
@aclements
Copy link
Member

@aclements aclements commented Aug 14, 2020

@randall77 , how do you feel about backporting this given the relatively high complexity of the CL? Is there a simpler fix that might be safer to backport?

@randall77
Copy link
Contributor Author

@randall77 randall77 commented Aug 14, 2020

I don't think there's really anything simpler. I could revert a bunch of the code deletion, but since it isn't called anyway (and is buggy regardless) I'm not sure that would help. The actual code addition is small.
I'm open to suggestions though.

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 14, 2020

Change https://golang.org/cl/248621 mentions this issue: cmd/compile: fix live variable computation for deferreturn

@dmitshur dmitshur modified the milestones: Go1.15.1, Go1.15.2 Sep 1, 2020
@dmitshur dmitshur modified the milestones: Go1.15.2, Go1.15.3 Sep 9, 2020
@randall77
Copy link
Contributor Author

@randall77 randall77 commented Sep 10, 2020

@dmitshur Why did this issue's fix not go out with 1.15.2? It looks like it didn't make it to CherryPickApproved, but why didn't it get to that state?

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Sep 10, 2020

@randall77 For a backport issue to get to CherryPickApproved state, someone on the release team needs to approve it. We've discussed this issue in past release meetings but a decision hasn't been made yet (though we are quite close by now). If there is a backport issue that you believe is critical and a minor release should not be made without that backport issue being considered (and either approved, or we find agreement not to block on it), the release-blocker label should be used to indicate that.

Also please see what I wrote here about the timing of backport issues and minor releases.

@randall77
Copy link
Contributor Author

@randall77 randall77 commented Sep 10, 2020

Ok, just wanted to make sure it wasn't missed.

@toothrot
Copy link
Contributor

@toothrot toothrot commented Sep 11, 2020

Approved. This is a serious issue with no workaround. As @dmitshur said, sorry for the delay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.