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: DTrace fails on macOS #17819

Closed
shibukawa opened this issue Nov 6, 2016 · 4 comments

Comments

Projects
None yet
5 participants
@shibukawa
Copy link

commented Nov 6, 2016

What version of Go are you using (go version)?

1.7.3

What operating system and processor architecture are you using (go env)?

amd64 on macOS 10.11.6 (El Capitan) and 10.12.1 (Sierra)
(System Integrity Protection is turned off to use DTrace)

What did you do?

package main

func main() {
}
$ sudo dtruss ./mycode

What did you expect to see?

Appears system call information

What did you see instead?

The panic message thrown at the following place appears.

https://github.com/golang/go/blob/master/src/runtime/os_darwin.go#L108

@moriyoshi researched this issue I met and he found the following facts:

The following codes works.

package main
import (
    "C"
)
func main() {
}
package main
import (
    "time"
)
func main() {
    // attach with $ sudo dtruss -p PID 
    // during this term
    time.Sleep(10 * time.Second)
}

bsdthread_register() function may be designed to be called only once (call twice returns error), but /usr/lib/dtrace/libdtrace_dyld.dylib calls this function before loading and then Go runtime calls at initialization process too (if the go program was not built in cgo mode).

@minux

This comment has been minimized.

Copy link
Member

commented Nov 6, 2016

@josharian josharian changed the title Go application doesn't work on DTrace on macOS cmd/link: DTrace fails on macOS Nov 7, 2016

@quentinmit

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2016

/cc @rsc

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2017

Dup of #17490.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2017

#18171 is about linking with at least runtime/cgo by default, to avoid this kind of bsdthread_register issue. So dup of #18171.

Although #17490 would solve this too, it's more than is necessary. (It's about not just linking with runtime/cgo by default but then using the system dylib for all system calls.)

@golang golang locked and limited conversation to collaborators Mar 8, 2018

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.