cmd/go: stacktraces with -trimpath don't use replaced module paths

[whereswaldon]

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!

[gabyhelp]

Related Issues and Documentation

• cmd/go: -trimpath with -mod=vendor doesn't trim path #36566 (closed)
• cmd/build: -trimpath is ignored when forcefully passing -gcflags=-trimpath=$SOMETHING #66849 (closed)
• cmd/go: panic in mod tidy when requiring main module #46078 (closed)
• runtime/debug: BuildInfo does not honour replace directives #37392 (closed)
• cmd/go: go build panics with empty old build constraints #44487 (closed)
• cmd/go: panic when go getting exp/slices and project contains old dependencies #61738 (closed)
• cmd/compile: unreachable panic with GODEBUG=gotypesalias=1 #65778 (closed)
• cmd/go: build_trimpath test doesn't correctly test executable reproducibility #35435 (closed)
• cmd/go: get: panic: internal error: can't find reason for requirement on golang.org/x/sync@... #56494 (closed)
• cmd/go: get panics with "can't find reason for requirement on" #47979 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

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.

[whereswaldon]

@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]

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