Go Profiling - Symbols not available

323 views
Skip to first unread message

Ross Light

unread,
Jun 25, 2011, 1:21:50 PM6/25/11
to golang-nuts
I just tried to profile my own program using the techniques in the
latest blog post (http://blog.golang.org/2011/06/profiling-go-
programs.html), and found that when I executed top10, all of the
function names were just memory addresses. I've checked the same
binary with GDB to ensure that debugging symbols are present. I'm
running weekly.2011-06-23 on Mac OS X 10.6.7 with 6g.

Cheers,
Ross Light

Ross Light

unread,
Jun 25, 2011, 3:21:45 PM6/25/11
to golang-nuts
I fixed my problem, but this seems like a bit of a hack.

In GetProcedureBoundaries (line 4738), nm will be run before 6nm
does. nm succeeds on my box and produces results for some low-level
symbols, but not for most of the code. By commenting out the other nm
calls, gopprof works fine. Am I supposed to be using gopprof
differently?

Cheers,
Ross Light

Dave Grijalva

unread,
Jun 25, 2011, 3:38:26 PM6/25/11
to golang-nuts
I had the same issue when I tried to do this using the latest weekly
release. Is there some argument I have to give somewhere to enable
this?

Welcome to pprof! For help, type 'help'.
(pprof) top
Total: 6846 samples
6846 100.0% 100.0% 6846 100.0% __cgo_allocate


-dave

andrey mirtchovski

unread,
Jun 25, 2011, 4:04:49 PM6/25/11
to Dave Grijalva, golang-nuts
using a profile generated by 6prof (instead of the -cpuprofile flag
described in the blog post) I don't see this issue at tip with a
binary that uses only pure go:

$ gopprof --interactive 6.out prof


Welcome to pprof! For help, type 'help'.

(pprof) top10
Total: 115 samples
74 64.3% 64.3% 74 64.3% runtime.mach_semaphore_wait
12 10.4% 74.8% 12 10.4% runtime.mach_semaphore_signal
8 7.0% 81.7% 8 7.0% runtime.cas
3 2.6% 84.3% 3 2.6% dequeue
3 2.6% 87.0% 25 21.7% runtime.chansend
3 2.6% 89.6% 11 9.6% runtime.xadd
2 1.7% 91.3% 2 1.7% memcopy
2 1.7% 93.0% 9 7.8% runtime.lock
1 0.9% 93.9% 1 0.9% enqueue
1 0.9% 94.8% 11 9.6% runtime.chanrecv

however, I do see the issue with binaries having something to do with
cgo and _crosscall (i'm not sure which). there 'nm' will print the
following, and cause gopprof to not revert to '6nm':

$ nm goinstall
U ___error
U ___stack_chk_fail
U ___stack_chk_guard
U ___stderrp
00000000000dc848 T __cgo_allocate
00000000000dc8f6 T __cgo_panic
U _abort
00000000000dc94d T _crosscall2
U _fprintf
U _fputc
U _free
U _freeaddrinfo
U _fwrite
U _gai_strerror
U _getaddrinfo
U _malloc
U _pthread_attr_getstacksize
U _pthread_attr_init
U _pthread_create
U _pthread_key_create
U _pthread_key_delete
U _pthread_setspecific

godoc and goinstall do this.

Russ Cox

unread,
Jun 27, 2011, 10:03:39 AM6/27/11
to andrey mirtchovski, Dave Grijalva, golang-nuts
There's a much bigger problem with pprof on OS X
than not being able to find symbols. OS X doesn't
reliably deliver the virtual cpu timer signal to the
thread that used up the cpu. See the description at
http://code.google.com/p/go/source/detail?r=35b716c94225

Russ

Reply all
Reply to author
Forward
0 new messages