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/link: delete source file path info in panic‘s stack trace for production releases #13809

Closed
johnjaylward opened this issue Jan 4, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@johnjaylward
Copy link

commented Jan 4, 2016

see #6819 for original discussion.

Using paths relative to GOROOT or GOPATH seems reasonable. Some benefits are:

  • Developer working directory would not be shown in production
  • Paths in stack traces would be more succinct, showing only the relevant parts of the path
  • Stack traces make sense across users and dev environments

@ianlancetaylor ianlancetaylor changed the title Delete source file path info in panic‘s stack trace for production releases cmd/link: delete source file path info in panic‘s stack trace for production releases Jan 4, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2016

Have you tried using GOROOT_FINAL? See the docs at https://golang.org/cmd/go/#hdr-Environment_variables .

@johnjaylward

This comment has been minimized.

Copy link
Author

commented Jan 4, 2016

I don't have GOROOT set currently. Is there a better doc on how to use both GOROOT and GOROOT_FINAL than that link? I'm unsure on how changing the values will affect my build environment or in what cases it will be used.

Also, if GO is only installed in my user directory, it doesn't look like this will help at all.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2016

There is not a better doc, no. You should not have GOROOT set. Just set GOROOT_FINAL and see what happens.

@johnjaylward

This comment has been minimized.

Copy link
Author

commented Jan 4, 2016

$ cat release.sh
#!/bin/bash
export GOROOT_FINAL=/usr/local/Cellar/go/1.5.1/libexec

GOOS=darwin GOARCH=amd64 go build -o execOSX
$ ./execOSX
panic: WOW

goroutine 1 [running]:
main.main()
    /Users/me/git/go_apps/src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

It still shows my user path. It doesn't appear to accomplish what I was looking for.

@minux

This comment has been minimized.

Copy link
Member

commented Jan 4, 2016

@johnjaylward

This comment has been minimized.

Copy link
Author

commented Jan 4, 2016

Setting the variable doesn't appear to do anything.

I can set it to /usr/local/go or /dev/null and my output is the same as being unset.

@minux

This comment has been minimized.

Copy link
Member

commented Jan 4, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2016

Closing as GOROOT_FINAL does seem to work in Go 1.6, and we aren't going to change this for Go 1.5.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2016

As I understood @jonjaylward's report, specifically this stack trace:

goroutine 1 [running]:
main.main()
    /Users/me/git/go_apps/src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

I believe the objection is to seeing /Users/me/git/go_apps, not to /usr/local/Cellar/go/1.5.1/libexec. (Please correct me if I am wrong.)

The GOROOT_FINAL variable would change /usr/local/Cellar/go/1.5.1/libexec to something else, but it has no effect on code in GOPATH, like /Users/me/git/go_apps/....

As for the request to hide GOPATH in the source file information, we won't remove that by default. It's actually incredibly useful, even in production, to see the full path used to build the software. I certainly want to preserve that.

However, if your local setup is such that removing the GOPATH prefix makes sense, the thing to do is to compile with

go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH

That would turn the above stack trace into:

goroutine 1 [running]:
main.main()
    src/test/main.go:24 +0x65

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1

Given this solution I don't think we need to reopen the issue. But I'm happy to do so if I misunderstood the request.

@johnjaylward

This comment has been minimized.

Copy link
Author

commented Jan 5, 2016

That solution is perfect and solves my issue. I was more concerned about the GOPATH than the GOROOT.

Can I pass multiple values to the trimpath in order to also trim both GOPATH and GOROOT if so desired?

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2016

For now you can only trim one prefix. We could plausibly make -trimpath take a list for Go 1.7. If that's useful to you please file a new issue. Thanks.

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