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: runtime `init` chain behaviour is changed after upgraded to 1.12.1 release #31175

Closed
lnshi opened this issue Apr 1, 2019 · 4 comments

Comments

Projects
None yet
4 participants
@lnshi
Copy link

commented Apr 1, 2019

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

go version go1.12.1 darwin/amd64

Does this issue reproduce with the latest release?

go1.12.1 is the latest release.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/u***/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/u***/go_projects"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/xw/fjl2c85x0psg7nm1sth8y_m40000gn/T/go-build587368583=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

main.go

package main

import (
  "******/b"
)

func main() {
  b.FuncB()
}

b.go

package b

func init() {
	// pc = program counter.
	pcs := make([]uintptr, 1)

	if n := runtime.Callers(3, pcs); n == 0 {
		// Should have no any chance to come here, lets panic.
		panic("daemon init not able to get proper program counters")
	}

	if fun := runtime.FuncForPC(pcs[0]); fun == nil || fun.Name() != "main.init" {
		// This project was not started from 'main.main()'.
		// Do something special...
		return
	}
}

func FuncB() {
}

Before i upgraded to go1.12.1, in above package b's init function, the caller's name fun.Name() will be different for the case:

  • I start the project from main.main (the fun.Name() will be main.init)
  • and the case i start the project by directly calling the FuncB in package b, like from some tests i do go b.FuncB() (the fun.Name will be something different, cannot remember)

After i upgraded to go1.12.1, now in either way i start the project, the fun.Name is always runtime.goexit

What was actually changed underlying? What potential issues it could cause?

@bronze1man

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

This commit?
d949d0b

I have an old issue #22387 may also relative to this one.

@josharian

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

@josharian josharian changed the title Runtime `init` chain behaviour is changed after upgraded to 1.12.1 release cmd/compile: runtime `init` chain behaviour is changed after upgraded to 1.12.1 release Apr 1, 2019

@josharian josharian added this to the Go1.13 milestone Apr 1, 2019

@randall77

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

This is intentional.

Tracebacks were modified in 1.12 to more accurately reflect the user's actual source code.
Part of that is to not report init function calls in tracebacks, because those calls (and the init functions themselves) aren't actually in user's code. For instance, there's no line number we can report for them. Init functions now appear to be called directly by the runtime.

So I think the way you were using tracebacks is unsupported. There's no way to detect that b was imported directly from main. And using tracebacks in 1.11 and earlier is fragile anyway; if b is also imported indirectly from main (main->a->b, say) then b's initialization may come from a and not main.

(Commit d949d0b is only in 1.13, so that isn't the cause. It's probably CL 159717)

@lnshi

This comment has been minimized.

Copy link
Author

commented Apr 15, 2019

@randall77 thanks for your explanations, for me this is totally fine: i just want to find out this is intentional or accidental, now i get the answer, so i guess we can close.

@lnshi lnshi closed this Apr 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.