-
Notifications
You must be signed in to change notification settings - Fork 479
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
uftrace for go language #557
Comments
It can be filtered with
|
Here is more verbose output.
|
@honggyukim GOOOOOOOD!! |
@honggyukim Great!!! |
Nice, I'll take a look later. |
It has to support multi-threaded go programs so it must work without By the way, I tested it with other go examples that include go routines and channels, and found that they both work fine. |
I suspect depth in goroutine will be mixed(?) and confusing. Could you please show me an example? |
$ cat go-routines.go
package main
import "fmt"
func f(from string) {
fmt.Println(from)
}
func main() {
f("direct")
go f("goroutine")
fmt.Scanln()
fmt.Println("done")
}
It shows that |
Here is an example for using channels. $ cat channels.go
package main
import "fmt"
func main() {
messages := make(chan string)
go func() {
messages <- "ping"
}()
msg := <-messages
fmt.Println(msg)
}
It shows that |
Hmm.. I tested with more complicated goroutine example from https://gobyexample.com/stateful-goroutines and found that it's too deeply nested because of multiple go routine instances.
It seems that we need to handle go routines somehow differently. |
Yes that what I worry about. We somehow need to figure out goroutine contexts and treat them as different threads. |
I've been testing uftrace for go language after talking to @taeguk last week.
1. Test program
Here is a simple
abc.go
program.2. Build and run
After building it with
-pg
option usinggccgo
, it runs same as normal execution.3. Run it with uftrace
Now I executed it with uftrace and found that it shows many error messages. However, it also shows the trace output which looks as expected from
main.main()
.4. Problem
I found that
mtdp
got null fromget_thread_data()
in multi-threaded mode.5. Bypassing the problem
There is an option to force to use
libmcount-single.so
that is implemented as a single threaded mode, so I used it. As shown in the below trace output, uftrace doesn't complain with--libmcount-single
now and the trace output looks fine.6. Simplified trace output only for main
Since go program calls many library calls before
main
function, I used--no-libcall
this time.The output almost looks what I expected from uftrace.
Thanks @taeguk for giving us the idea!
The text was updated successfully, but these errors were encountered: