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/ld cannot delete source file path info in panic‘s stack trace #6819

Closed
gopherbot opened this issue Nov 22, 2013 · 12 comments
Closed

cmd/ld cannot delete source file path info in panic‘s stack trace #6819

gopherbot opened this issue Nov 22, 2013 · 12 comments

Comments

@gopherbot
Copy link

by flhshark:

I used  -ldflags "-s -w“  to build program.  
but source file path still showed up in panic‘s stack trace
like this:

panic: test

goroutine 1 [running]:
runtime.panic(0x5378a0, 0x134a6670)
        C:/data/gosrc/go/src/pkg/runtime/panic.c:266 +0xa6
main.makeDB(0xc8741e00, 0xe, 0x0, 0x6544c0, 0xcc353380, ...)
        C:/data/hg-repo/src/go/sf2db/main.go:58 +0x403
main.main()
        C:/data/hg-repo/src/go/sf2db/main.go:25 +0xd9

goroutine 3 [syscall]:
runtime.goexit()
        C:/data/gosrc/go/src/pkg/runtime/proc.c:1394

What is the expected output?
source file path and function name should not print.

What do you see instead?
source file path showed up like below:
 C:/data/hg-repo/src/go/sf2db/main.go:25 +0xd9

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g,8g

Which operating system are you using?
win7 64bit

Which version are you using?  (run 'go version')
go1.2rc5

Please provide any additional information below.
@ianlancetaylor
Copy link
Contributor

Comment 1:

If ld deleted the source file information, then runtime.Caller would not work.  That in
turn means that standard packages like log would not work.  So this seems like a good
thing to me.

Status changed to WorkingAsIntended.

@ianlancetaylor
Copy link
Contributor

Comment 2:

If ld deleted the source file information, then runtime.Caller would not work.  That in
turn means that standard packages like log would not work.  So this seems like a good
thing to me.

@minux
Copy link
Member

minux commented Nov 22, 2013

Comment 3:

the problem is that it used to work on Go 1.1.
Go 1.2 heavily relies on pclntab, so -s doesn't remove it anymore, which is the problem.

@ianlancetaylor
Copy link
Contributor

Comment 4:

OK, I'll reopen.
But since doing this will cause some reasonable Go programs to fail strangely, I think
we need to ask: what is the goal?

Status changed to New.

@rsc
Copy link
Contributor

rsc commented Nov 22, 2013

Comment 5:

It was an accident of history that -s did this in Go 1.1. It was not intended. Unless
someone wants to argue against it, I think this is now working as intended. That is, the
change from Go 1.1 to Go 1.2 is fine.

Status changed to WorkingAsIntended.

@gopherbot
Copy link
Author

Comment 6 by flhshark:

the goal is, release version exe file should not contain source file info .
maybe you should provide a build option to control output is for debug or
release(contain source info or not )

@gopherbot
Copy link
Author

Comment 7:

This is a classic conversation about not "leaking" local file paths. Perhaps a good
compromise would be to include path names relative to $GOPATH. The above stack trace
would then contain e.g. "runtime/panic.c" and "sf2db/main.go", with the typical source
path looking more like "github.com/jdoe/foo/bar/baz.go".

@gopherbot
Copy link
Author

Comment 8 by r04r@minichan.org:

Would also like to see this. Path information of the developer's system should not wind
up in production binaries.

@johnjaylward
Copy link

I agree, I don't see why developer path information is included in trace output. Could it not at least be a relative path from GO_ROOT?

@minux
Copy link
Member

minux commented Jan 3, 2016 via email

@johnjaylward
Copy link

but if I'm running an executable in production, there is no "source" available anyway. In a DEV env, the relative path to GO_ROOT should work and in produciton, it shouldn't fail any differently than it does now.

@ianlancetaylor
Copy link
Contributor

This issue was closed long ago. Please open a new issue or discuss this issue on the golang-dev mailing list. Thanks.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants