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

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. :smile: Thanks!

Comment From: gabyhelp

Related Issues and Documentation

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

Comment From: 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.

Comment From: 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.