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/go: stacktraces with -trimpath don't use replaced module paths #68493

Closed
whereswaldon opened this issue Jul 17, 2024 · 4 comments
Closed

Comments

@whereswaldon
Copy link
Contributor

Go version

go version go1.22.2 linux/amd64

Output of go env in your module/workspace:

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/chris/.cache/go-build'
GOENV='/home/chris/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/chris/Code/go/pkg/mod'
GONOPROXY='redacted'
GONOSUMDB='redacted'
GOOS='linux'
GOPATH='/home/chris/Code/go'
GOPRIVATE='redacted'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/chris/.local/lib/go-1.22.2'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/chris/.local/lib/go-1.22.2/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/chris/Code/gioui/example/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3599193407=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I built a Go program using a replace directive for gioui.org to point at a fork.

git clone --branch=replace-crash https://git.sr.ht/~whereswaldon/gio-example
cd gio-example
go build -o hello.out -trimpath ./hello

What did you see happen?

When that program crashes due to a panic in the replaced dependency, the stacktrace uses the un-replaced module version in the stacktrace:

$ ./hello.out
panic: artificial panic

goroutine 19 [running]:
gioui.org/app.(*Window).Event(...)
	gioui.org@v0.7.0/app/window.go:715
main.loop(0x0?)
	gioui.org/example/hello/hello.go:35 +0xa5
main.main.func1()
	gioui.org/example/hello/hello.go:22 +0x38
created by main.main in goroutine 1
	gioui.org/example/hello/hello.go:20 +0x1a

When I run go version -m hello.out, I see:

$ go version -m hello.out 
hello.out: go1.22.2
	path	gioui.org/example/hello
	mod	gioui.org/example	(devel)	
	dep	gioui.org	v0.7.0
	=>	git.sr.ht/~whereswaldon/gio	v0.0.0-20240717140507-395bbbc24e41	h1:pirMjkZKXbc/74E3M02Kb8iJnrr1OSwAZv3a8/XHMsg=
	
	dep	gioui.org/cpu	v0.0.0-20210817075930-8d6a761490d2	h1:AGDDxsJE1RpcXTAxPG2B4jrwVUJGFDjINIPi1jtO6pc=
	dep	gioui.org/shader	v1.0.8	h1:6ks0o/A+b0ne7RzEqRZK5f4Gboz2CfG+mVliciy6+qA=
	dep	github.com/go-text/typesetting	v0.1.1	h1:bGAesCuo85nXnEN5LmFMVGAGpGkCPtHrZLi//qD7EJo=
	dep	golang.org/x/exp	v0.0.0-20240707233637-46b078467d37	h1:uLDX+AfeFCct3a2C7uIWBKMJIR3CJMhcgfrUAqjRK6w=
	dep	golang.org/x/exp/shiny	v0.0.0-20240707233637-46b078467d37	h1:SOSg7+sueresE4IbmmGM60GmlIys+zNX63d6/J4CMtU=
	dep	golang.org/x/image	v0.18.0	h1:jGzIakQa/ZXI1I0Fxvaa9W7yP25TqT6cHIHn+6CqvSQ=
	dep	golang.org/x/sys	v0.22.0	h1:RI27ohtqKCnwULzJLqkv897zojh5/DwS/ENaMzUOaWI=
	dep	golang.org/x/text	v0.16.0	h1:a94ExnEXNtEwYLGJSIUxnWoxoRz/ZcCsV63ROupILh4=
	build	-buildmode=exe
	build	-compiler=gc
	build	-trimpath=true
	build	DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
	build	CGO_ENABLED=1
	build	GOARCH=amd64
	build	GOOS=linux
	build	GOAMD64=v1
	build	vcs=git
	build	vcs.revision=75ef8c632b492cf913c870967969a17f0c72d8bf
	build	vcs.time=2024-06-27T19:54:00Z
	build	vcs.modified=true

What did you expect to see?

I expect the stacktrace to show git.sr.ht/~whereswaldon/gio@v0.0.0-20240717140507-395bbbc24e41 as the module name of the code that generated the panic.

More generally, I expect the stacktrace to always refer to the code actually included in the executable, and not just the version in the require directive in go.mod.

I know I used -trimpath when building. This issue does not exist without -trimpath. However, the executable still contains the info needed to show the correct module.

If the replace were to a local filesystem path instead of a different repo, I know -trimpath might discard the info necessary to print a perfectly accurate path, but could that be displayed as [path trimmed]/file.go?

I know that this is likely a complex problem, and maybe my expectations are simply unreasonable. Please educate me if that is the case. 😄 Thanks!

@seankhliao seankhliao changed the title build: -trimpath creates misleading panic stack traces despite having enough info to do otherwise cmd/go: stacktraces with -trimpath don't use replaced module paths Jul 17, 2024
@seankhliao
Copy link
Member

I don't think the code you provided reproduces the issue.

That said, replace changes just the code for a module, not the identity. The names used are still all before the replace is applied, and even the replacing module will claim its identity is the original one. A module name does not strictly correlate to where the source code was obtained from, it is only by convention/convenience that it most of the time they are the same.

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Jul 17, 2024
@whereswaldon
Copy link
Contributor Author

@seankhliao My apologies, apparently there was a commit waiting to be pushed to my reproducer branch. Please try it again.

Here's what I see:

$ go build -o hello.out ./hello
$ ./hello.out
panic: artificial panic

goroutine 6 [running]:
gioui.org/app.(*Window).Event(...)
	/home/chris/Code/go/pkg/mod/git.sr.ht/~whereswaldon/gio@v0.0.0-20240717140507-395bbbc24e41/app/window.go:715
main.loop(0x0?)
	/tmp/gio-example/hello/hello.go:35 +0xa5
main.main.func1()
	/tmp/gio-example/hello/hello.go:22 +0x38
created by main.main in goroutine 1
	/tmp/gio-example/hello/hello.go:20 +0x1a
$ go build -o hello.out -trimpath ./hello
$ ./hello.out
panic: artificial panic

goroutine 6 [running]:
gioui.org/app.(*Window).Event(...)
	gioui.org@v0.7.0/app/window.go:715
main.loop(0x0?)
	gioui.org/example/hello/hello.go:35 +0xa5
main.main.func1()
	gioui.org/example/hello/hello.go:22 +0x38
created by main.main in goroutine 1
	gioui.org/example/hello/hello.go:20 +0x1a

The path is what I expect if I do not use -trimpath, but is incorrect if -trimpath has been applied.

@whereswaldon
Copy link
Contributor Author

@seankhliao Could you take a look at the above output?

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

No branches or pull requests

3 participants