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

cmd/compile: devirtualization changes program behavior #52072

Open
go101 opened this issue Mar 31, 2022 · 5 comments
Open

cmd/compile: devirtualization changes program behavior #52072

go101 opened this issue Mar 31, 2022 · 5 comments
Labels
NeedsInvestigation

Comments

@go101
Copy link

@go101 go101 commented Mar 31, 2022

Moved from #38634 (comment).

What version of Go are you using (go version)?

$ go version
go version go1.18 linux/amd64

It looks this problem started from Go 1.16.

Does this issue reproduce with the latest release?

Yes

What did you do?

package main

type I interface{ M() }

type T struct{}

func (T) M() {}

var pt *T

func f() (r int) {
	defer func(){recover()}()

	var i I = pt
	defer i.M()
	r = 1
	return
}

func g()(r int) {
	defer func(){recover()}()

	var i I = pt
	f := i.M
	defer f()
	r = 1
	return
}

func main() {
	println(f()) // 0
	println(g()) // 1
}

[edit]: another example:

package main

type I interface{ M() }

type T struct{
	x int
}

func (t T) M() {
	println(t.x)
}

func f() {
	var t = &T{1}
	var i I = t
	defer i.M()
	t.x = 2
	return
}

func g() {
	var t = &T{1}
	var i I = t
	f := i.M
	defer f()
	t.x = 2
	return
}

func main() {
	f() // 1
	g() // 2
}

What did you expect to see?

Same return results.

What did you see instead?

Different results.

Changing the i variable to global makes this inconsistency gone.

@cuonglm cuonglm added the NeedsInvestigation label Mar 31, 2022
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Mar 31, 2022

In f, i.M can be devirtualized to *T, while in g, it does not. So defer i.M() becomes defer pt.M(), and pt is evaluated as nil pointer dereference.

Changing i to a global variable make it can not be devirtualized in both cases.

@zitudu
Copy link

@zitudu zitudu commented Apr 2, 2022

This is consistent with the specification of Defer statements and Selectors.

For defer i.M() in f, i is nil, and panic immediately.

If a deferred function value evaluates to nil, execution panics when the function is invoked, not when the "defer" statement is executed.

g uses the selector and gets the (*T).M method, then defer calls the method and results in run-time panic.

  1. For a value x of type I where I is an interface type, x.f denotes the actual method with name f of the dynamic value of x. If there is no method with name f in the method set of I, the selector expression is illegal.
  1. If x is of interface type and has the value nil, calling or evaluating the method x.f causes a run-time panic.

@go101
Copy link
Author

@go101 go101 commented Apr 2, 2022

If a deferred function value evaluates to nil, execution panics when the function is invoked, not when the "defer" statement is executed.

So the r = 1 statement in f should be executed by the spec, right?

[Update]: so the core of the problem is whether or not i.M in defer i.M() should be expanded to the concrete method.
Whatever, the results should be the same regardless of i is global or not.

So this is a bug undoubtedly.

@zitudu
Copy link

@zitudu zitudu commented Apr 2, 2022

If a deferred function value evaluates to nil, execution panics when the function is invoked, not when the "defer" statement is executed.

So the r = 1 statement in f should be executed by the spec, right?

You're right... I read the specs again. I think it should be like this:

when defer is executed, it will first calculate the function address and parameters (if any), and then invoke the function before returns. The problem is that nil is encountered when getting the function address.

Defer:

Each time a "defer" statement executes, the function value and parameters to the call are evaluated as usual and saved anew but the actual function is not invoked. Instead, deferred functions are invoked immediately before the surrounding function returns, in the reverse order they were deferred. That is, if the surrounding function returns through an explicit return statement, deferred functions are executed after any result parameters are set by that return statement but before the function returns to its caller. If a deferred function value evaluates to nil, execution panics when the function is invoked, not when the "defer" statement is executed.

Calls:

A method call x.m() is valid if the method set of (the type of) x contains m and the argument list can be assigned to the parameter list of m. If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m()

@go101 go101 changed the title cmd/compile: self-inconsistency in compiling deffered method calls cmd/compile: devirtualization changes program behavior Apr 8, 2022
@go101
Copy link
Author

@go101 go101 commented Apr 14, 2022

For the first second example shown above, the outputs are 2 2 with gccgo.
Personally, I think gccgo is right here, for it is self-consistent.

But the outputs of the following program is 2 1 for gccgo and 1 1 for gc.
I don't know who is right here. [edit]: Sorry, it looks gccgo and gc agree on the outputs of g. So the following example is the same as the above ones in principle. So gccgo is also right here.

@ianlancetaylor @griesemer

package main

type I interface{ M() }

type T struct{
	x int
}

func (t T) M() {
	println(t.x)
}

func f() {
	var t = &T{1}
	var i I = t
	defer i.M()
	t.x = 2
	return
}

func g() {
	var t = &T{1}
	var i I = t
	f := i.M
	defer f()
	i = &T{2}
	return
}

func main() {
	f()
	g()
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation
Projects
None yet
Development

No branches or pull requests

3 participants