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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@lnshi
Copy link

lnshi 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
Copy link
Contributor

bronze1man commented Apr 1, 2019

This commit?
d949d0b

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

@josharian
Copy link
Contributor

@randall77

@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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 1, 2019
@josharian josharian added this to the Go1.13 milestone Apr 1, 2019
@randall77
Copy link
Contributor

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
Copy link
Author

lnshi 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 as completed Apr 15, 2019
@golang golang locked and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants